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Abstract 

This  research  proposes  and  evaluates  a  methodology  for  reengineering  a 
relational  database  to  an  object-oriented  database.  We  applied  this  methodology  to 
reengineering  the  Air  Force  Institute  of  Technology  Student  Information  System 
(AFITSIS)  as  our  test  case.  With  this  test  case,  we  could  verify  the  applicability  of  the 
proposed  methodology,  especially  because  AFITSIS  comes  from  an  old  version  of 
Oracle  RDBMS.  We  had  the  opportunity  to  implement  part  of  the  object  model  using 
an  object-oriented  database,  and  we  present  some  peculiarities  encountered  during  this 
implementation.  The  most  important  result  of  this  research  is  that  it  demonstrated  that 
the  proposed  methodology  can  be  used  for  reengineering  an  arbitrarily  selected 
relational  database  to  an  object-oriented  database.  It  appears  that  this  approach  can  be 
applied  to  any  relational  database. 
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A  METHODOLOGY  FOR  REENGINEERING  RELATIONAL 


DATABASES  TO  AN  OBJECT-ORIENTED  DATABASE 

1  Introduction 

The  software  reengineering  process  has  been  used  to  solve  many  problems 
involving  legacy  systems.  It  has  been  helping  companies  to  recover  and  to  update 
documentation,  design,  and  requirements  of  important  systems.  Most  of  the  time 
thousands  of  lines  of  code  are  the  only  source  of  the  business  rules,  and  are  the  starting 
point  in  the  process  of  reverse  engineering.  Software  reengineering  has  been  playing 
an  important  role  and  has  been  proven  to  be  very  effective  in  extending  the  lifetime  of 
many  applications. 

All  systems  have  a  limited  lifetime.  Each  implemented  change  erodes  the 
structure  which  makes  any  following  changes  more  expensive.  As  time  goes  on,  the 
cost  to  implement  a  change  will  be  too  high,  and  the  system  will  not  be  able  to  support 
its  intended  task.  The  reengineering  process  plays  an  important  role  by  not  allowing 
the  system  to  reach  this  condition. 

1.1  Background. 

The  goal  of  reengineering  is  to  mechanically  reuse  past  development  efforts  in 
order  to  reduce  maintenance  expense  and  improve  software  flexibility.  Reengineering 
is  applicable  to  diverse  software  such  as  programming  code,  databases,  and  inference 
logic  [1]. 

There  are  many  possible  motives  for  the  reverse  engineering  of  databases  [2] : 
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•  Migration  between  database  paradigms.  One  may  want  to  migrate 
between  database  paradigms,  for  example  from  past  hierarchical,  network, 
and  relational  databases  to  modern  relational  and  object-oriented  databases; 

•  Migration  within  a  database  paradigm.  A  more  mundane  task  would  be 
to  migrate  between  different  implementations  of  a  database  paradigm,  for 
example  from  one  vendor’s  relational  database  to  another  relational 
database; 

•  Documentation.  Reverse  engineering  can  elucidate  poorly  documented 
existing  software  when  the  developers  are  no  longer  available  for  advice; 

•  Tentative  requirements.  Reverse  engineering  of  existing  software  can 
yield  tentative  requirements  for  the  new  replacement  system.  Reverse 
engineering  ensures  that  the  functionality  of  the  existing  system  is  not 
overlooked  or  forgotten; 

•  Assessment  of  software.  The  quality  of  the  database  design  is  an  indicator 
of  the  quality  of  the  software  as  a  whole.  An  understanding  of  the  concepts 
supported  by  the  underlying  database  schema  allows  one  to  better  judge 
functionality  claims; 

•  Integration.  Reverse  engineering  facilitates  integration  of  related  legacy 
applications  and  purchased  applications.  A  logical  model  of  encompassed 
software  is  a  prerequisite  for  integration; 
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•  Conversion  of  legacy  data.  One  must  fully  understand  the  logical 
correspondence  between  the  old  database  and  the  new  database  before 
attempting  to  convert  data. 

1.2  Problem. 

The  main  difficulty  to  reengineering  relational  databases  is  the  lack  of  a  robust 
process  that  can  be  applied  in  all  cases.  Most  of  the  existing  processes  for  database 
reverse  engineering  are  inadequate;  they  assume  too  high  a  quality  of  input  information 
[2]. 

1.3  Hypothesis. 

The  maintenance  of  a  relational  database  application  can  be  improved  by: 

1.  Reverse  engineering  the  system  to  develop  an  object-oriented  model; 

2.  Redesigning  the  system  using  an  Object-Oriented  Methodology; 

3.  Changing  the  Database  Management  System  to  one  that  supports  an  object- 
oriented  approach. 

1.4  Research  Objectives. 

In  order  to  solve  the  problem  stated  above  and  establish  the  validity  of  the 
above  hypothesis,  the  following  objectives  were  established: 

1.  Define  an  appropriate  reverse-engineering  methodology; 

2.  Determine  an  appropriate  database  application  to  be  a  test  case; 

3.  Analyze  and  reverse  engineer  the  test  case  using  this  methodology; 

4.  Redesign  the  test  case  using  object-oriented  methods; 
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5.  Implement  a  portion  of  the  new  design  in  an  Objeet-Oriented  Database 
Management  System  prototype  system; 

6.  Analyze  the  methodology  based  on  this  experience. 

1.5  Test  case. 

With  the  intention  of  conducting  directly  useable  research  in  the  field  of 
software  reengineering,  the  director  of  the  Communication  Computer  System  of  the  Air 
Force  Institute  of  Technology  (AFIT/SC)  was  contacted.  Discussions  led  to  the 
discovery  that  his  working  group  was  facing  a  significant  reengineering  task  which 
could  be  used  as  a  basis  test  case  for  this  thesis  research. 

In  1987  the  Air  Force  Institute  of  Technology  (AFIT)  contracted  the 
development  of  an  automated  system  called  Student  Tracking  and  Registration  System 
(STARS).  This  system  is  used  for  scheduling  courses,  registering  students  in  courses, 
tracking  academic  histories  of  students,  and  generating  related  reports.  The  STARS 
application  uses  the  Structured  Query  Language  (SQL)  to  access  an  Oracle  Relational 
Database  Management  System  (RDBMS)  Version  6.  This  system  also  uses  the 
following  tools:  the  SQL-Forms,  SQL-ReportWriter,  SQL-Menu,  VMS,  and  Batch 
files  [3] .  From  the  time  the  system  was  designed  until  this  thesis  effort,  requirements 
have  been  changing.  Some  of  these  changes  were  implemented,  while  others  were  not. 

Even  though  this  system  is  only  eight  years  old,  it  is  already  considered  old  or  a 
legacy  system.  This  quick  obsolescence  was  caused  mainly  by  the  following  [4]: 

1.  Changes  were  made  to  incorporate  some  new  requirements;  however, 
documentation  was  not  updated; 
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2. 


Past  leaders  who  lacked  software  knowledge; 


3.  New  technology; 

4.  Poor  training; 

5.  Lack  of  focus  on  changing  needs. 

The  Air  Force  Institute  of  Technology  Student  Information  System  (AFITSIS) 
was  chosen  as  the  test  case  in  implementing  a  new  method  for  reengineering  relational 
databases  to  an  Object-Oriented  database. 

AFITSIS  is  currently  designed  and  implemented  using  relational  technology  and 
unfriendly  user  interface  mechanisms.  This  old  design  and  technology  cause  the 
maintenance  to  be  difficult,  because  there  are  no  maintainability  feamres.  This  lack  of 
maintainability  demands  a  lot  of  time  and  effort  every  time  new  requirements  are 
implemented  on  the  system.  Additionally,  the  system  is  inflexible  and  complex, 
requiring  for  each  change  up  to  five  hundred  forms  and  reports  to  be  updated  and 
checked  for  consistency. 

1.6  Assumptions. 

The  following  assumptions  were  made  for  the  thesis  research: 

1.  The  decision  to  reengineer  AFITSIS  instead  of  starting  the  analysis  and 
design  of  a  new  system  is  the  best  decision; 

2.  Access  to  AFITSIS  and  query  information  from  the  database  are  available; 

3.  Access  to  an  Object-Oriented  Database  Management  System  (OODBMS)  is 
available  for  use. 
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1.7  Sequence  of  Presentation. 


The  thesis  is  divided  into  six  ehapters.  Chapter  I,  Introduction,  has  provided  an 
overview  of  the  work.  Chapter  II,  Summary  of  Current  Knowledge,  discusses  the 
background  information  which  provides  the  foundation  for  this  research.  Chapter  III, 
The  Methodology,  presents  a  proposed  methodology  for  reengineering  a  relational 
database  to  an  object-oriented  database.  Chapter  IV,  Application  of  the  Methodology, 
presents  the  application  of  the  proposed  methodology  using  AFITSIS  as  a  test  case. 
Chapter  V,  Implementation  Issues,  discusses  how  the  selected  part  of  AFITSIS  was 
implemented  using  an  OODBMS.  Lastly,  Chapter  VI,  Analysis,  Conclusions,  and 
Recommendations,  analyzes  the  results  obtained  from  the  application  and 
implementation  of  the  methodology,  draws  conclusions  from  this  analysis,  and  makes 
recommendations  for  futures  applications  of  this  methodology. 
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2  Summary  of  Current  Knowledge 


2.1  Treatment  and  Organization. 

This  literature  review  provides  the  foundation  to  create  a  methodology  for 
reengineering  relational  database  applications  to  an  object-oriented  database.  This 
chapter  is  divided  into  three  sections;  software  reengineering,  reengineering  of 
relational  databases,  and  object-oriented  methodology.  The  software  reengineering 
section  gives  an  overview  of  the  software  reengineering  process.  The  reengineering  of 
relational  databases  section  presents  the  basic  steps  when  reverse  engineering  relational 
databases.  The  object-oriented  methodology  section  describes  the  stages  used  by 
developers  to  analyze  a  problem,  design  a  system,  and  implement  the  system  into  a 
usable  product. 

2.2  Software  Reengineering. 

Reengineering,  also  viewed  as  both  renovation  and  reclamation,  is  the 
examination  and  alteration  of  a  system  to  reconstitute  it  in  a  new  form.  Reengineering 
usually  includes  some  form  of  reverse  engineering  (to  achieve  a  more  abstract 
description)  followed  by  some  form  of  forward  engineering  or  re-structuring  [5] . 

Reverse  engineering  is  a  process  of  examination  and  analysis  of  the  subject  to 
identify  its  components  and  create  a  higher  level  form  of  abstraction  [5] .  It  can  start  at 
any  stage  of  the  life-cycle  and  it  does  not  involve  changes  to  the  subject.  Its  sub¬ 
products  include  the  design  recovery  and  the  redocumentation  of  the  subject.  Forward 
engineering  can  be  easily  understood  as  a  process  of  moving  from  a  high-level  of 
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abstraction  to  low-level  or  physical  details.  It  is  the  same  as  the  traditional  method  of 
developing  a  new  system.  This  term  is  used  only  to  distinguish  this  process  from 
reverse  engineering.  Figure  1  illustrates  the  basic  ideas  of  software  reengineering 
using,  for  simplicity,  only  three  life-cycle  stages  of  software. 


Requirements 

(business  rules) 


Design 


Implementation 


Forward 


Forward 


engineering 


engineering 


Renovation 


Renovatio] 


engineering 


ngineermg 


^esi^ 

re^very 


Design 


recovery 


Redocumentation, 

restructuring 


Restructuring 


Restructuring 


Figure  1:  Relationship  between  terms  [5] 
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The  objectives  of  Software  reengineering  can  be  grouped  into  four  main  areas 


[6]: 

1.  Improve  maintainability.  The  maintenance  efforts  can  be  reduced  by 
reengineering  smaller  modules  with  more  explicit  interfaces.  However,  it  is 
not  easy  to  measure  progress  toward  this  goal. 

2.  Migration.  This  task  usually  deals  with  altering  and  converting  program 
structure.  This  goal  can  be  easily  measured,  since  the  system  will  perform 
the  same  operation  in  the  new  environment. 

3.  Achieve  greater  reliability.  This  goal  can  be  easily  reached  because  the 
restrucmring  process  usually  causes  most  of  the  potential  defects  to  appear. 
The  other  factor  that  contributes  to  better  software  reliability  is  the  extensive 
testing  required  to  prove  the  functional  equivalence  between  the  old  and  the 
new  system.  This  goal  can  be  readily  measured  by  fault  analysis. 

4.  Preparation  for  functional  enhancement.  Once  the  programs  are 

decomposed  into  smaller  modules,  it  is  easier  to  isolate  them  from  one 
another.  This  makes  it  simpler  to  change  or  add  new  functions  without 
affecting  other  modules. 


2.3  Reengineering  of  Relational  Databases. 

The  goal  of  reengineering  is  to  mechanically  reuse  past  development  efforts  in 
order  to  reduce  maintenance  expense  and  improve  software  flexibility.  According  to 
Hainaut  [7]  the  most  tractable  approach  for  database  applications  is  to  first  reverse 
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engineering  the  database  and  then  deal  with  the  programming  code.  Object-oriented 
models  provide  a  natural  language  for  facilitating  the  reengineering  process.  An 
object-oriented  model  can  describe  the  existing  software,  the  reverse-engineering 
semantic  intent,  and  the  forward-engineered  new  system. 

In  general,  the  mapping  between  object  models  and  a  database  schema  is  many- 
to-many.  Various  optimizations  and  design  decisions  can  be  used  to  forward  engineer 
an  object  model  into  a  database  schema.  Similarly,  when  reverse  engineering  a 
database,  alternate  interpretations  of  the  structure  and  data  can  yield  different  object 
models.  Usually  there  is  no  obvious,  single  correct  answer  for  reverse  engineering. 
Multiple  interpretations  can  all  yield  plausible  results  [2] . 

A  good  way  to  begin  reverse  engineering  is  by  entering  the  existing  schema  into 
a  CASE  tool.  Associations  will  often  be  found  in  a  degraded  form  such  as  relational 
database  foreign  keys.  Inheritance  must  be  implemented  in  a  degraded  marmer  for 
current  relational  database  managers.  The  schema  may  then  be  gradually  transformed 
to  a  logical  model  as  underlying  relationships  are  inferred. 

Jacobson  [8]  presents  a  good  approach  for  reengineering  old  systems  to  an 
object-oriented  architecture,  but  he  does  not  give  much  information  when  dealing  with 
relational  databases.  The  same  problem  exists  when  considering  other  approaches  for 
reengineering  like  those  of  Bennett  [9]  and  Sneed  [6];  they  are  not  focusing  on 
relational  databases. 

A  good  approach  is  suggested  by  Blaha  [1],  [2].  His  papers  present  some 
typical  implementation  strategies  that  are  used  for  forward  engineering.  He  explains  in 
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detail  each  step  to  be  taken  for  reverse  engineering  of  relational  databases.  The  basic 
steps  he  suggests  are: 

Step  1.  Prepare  an  initial  object  model. 

•  Represent  each  table  as  a  tentative  class.  All  columns  of  tables 
become  attributes  of  classes. 

Step  2.  Determine  candidate  keys. 

•  Look  for  unique  indexes.  Automated  scanning  of  data  can  yield 
potential  candidate  keys. 

Step  3.  Determine  foreign-key  groups. 

•  Try  to  resolve  homonyms,  attributes  with  the  same  name  that  refer  to 
different  things,  and  synonyms,  attributes  with  different  names  that 
refer  to  the  same  thing. 

•  Matching  attribute  names,  data  types,  and/or  domains  may  suggest 
foreign  keys. 

•  During  this  step  do  not  attempt  to  determine  specific  reference- 
referent  attribute  pairs  -  but  merely  groups  of  attributes  within  which 
foreign  keys  may  be  found. 

Step  4.  Refine  tentative  classes. 

•  Agglomerate  horizontally  partitioned  classes  into  a  single  class, 
(horizontally  partitioned  classes  must  also  have  the  same  semantic 
intent.) 

•  Detect  functions  and  constraints  that  are  represented  as  tables. 
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Step  5.  Discover  generalizations. 

•  Analyze  large  foreign-key  groups,  particularly  those  with  5,  10,  or 
more  cross-related  attributes. 

•  Look  for  patterns  of  many  replicated  attributes. 

•  Look  for  patterns  of  data  where  a  class  has  mumally  exclusive  subsets 
of  attributes. 

•  When  discovering  generalizations  do  not  forget  there  may  be  a  forest 
of  generalizations  with  multiple  superclass  roots  and  intermediate 
levels. 

Step  6.  Discover  associations. 

•  Convert  a  tentative  class  to  an  association  when  a  eandidate  key  is  a 
concatenation  of  two  or  more  foreign  keys. 

•  Introduce  a  qualified  association  when  a  candidate  key  combines  a 
foreign  key  with  non-foreign  key  attributes. 

•  The  remaining  associations  are  buried  and  manifest  as  foreign  keys. 

•  Note  minimum  multiplicity  for  associations.  Optional  multiplicity  is 
the  permissive  case;  a  lower  limit  of  one  (or  another  number)  is  more 
restrictive. 

•  Note  maximum  multiplieity  for  associations.  Many  multiplicity  is  the 
permissive  case;  an  upper  limit  of  one  (or  another  number)  is  more 
restrictive. 
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•  Apply  semantic  understanding  and  restate  some  associations  as 
aggregations.  Aggregation  is  the  “a-part-of”  relationship. 

Step  7.  Perform  transformation. 

•  Convert  a  class  to  a  link  class  as  needed. 

•  Lightweight  one-to-one  associations  should  be  more  simply 
represented  as  an  attribute. 

•  Nonatomic  n-ary  associations  should  be  decomposed  into  their 
constiment  associations  of  lesser  order. 

•  Consider  shifting  associations  via  transitive  closure. 

•  Double-buried  associations  should  be  merged  into  a  single 
association. 

•  You  may  need  to  insert  an  intermediate  class  in  a  generalization 
hierarchy  to  recognize  common  semantics,  attributes,  and 
associations. 

•  Transitive  closure  also  arises  through  the  combination  of 
generalization  and  association.  Where  possible,  eliminate  an 
imprecise  association  to  a  superclass  in  favor  of  a  more  restrictive 
association  to  a  subclass. 

•  Similarly,  eliminate  associations  to  subclasses  by  recognizing  patterns 
of  commonality. 
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2.4  Object-Oriented  Methodology. 


One  of  the  primary  reasons  for  adopting  object  technology  is  the  promise  of 
faster  development  and  reduced  maintenance  costs.  In  traditional  systems,  ongoing 
maintenance  costs  amount  to  more  than  80%  of  the  overall  cost  of  the  system  [10]. 
Object-oriented  systems  promise  to  reduce  maintenance  costs  through  reusable  objects 
that  can  dramatically  reduce  maintenance.  In  many  cases,  developers  only  need  to 
identify  an  object  class  that  functions  like  the  object  that  they  desire  to  create,  and 
specify  the  differences  between  the  object  and  their  new  object.  This  type  of  code 
reusability  can  dramatically  reduce  development  and  maintenance  costs. 

Object-oriented  methodology  allows  developers  to  analyze  problems  and  divide 
them  into  entities  residing  in  specific  states  and  exhibiting  certain  dynamic  behaviors. 
The  entities  become  objects  in  the  system.  The  designer  defines  the  relationships 
between  the  objects  to  determine  how  the  system  functions  as  a  whole.  The  four 
specific  stages  of  object-oriented  methodology  are  [11:4-6]: 

1.  Analysis.  During  the  analysis  stage,  the  developer  defines  the  system 
requirements.  Objects  are  identified  and  their  relationships  to  other  objects 
are  recorded.  There  are  no  implementation  decisions  in  this  stage.  Three 
models  are  defined  in  this  stage:  an  object  relationship  model,  a  dynamic 
model,  and  a  functional  model; 

2.  System  Design.  In  this  stage  the  system’s  architecture  is  determined.  The 
application  is  broken  into  subsystems.  Control  mechanisms  are  defined  for 
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each  subsystem.  The  focus  is  on  what  needs  to  be  done,  and  not  how  it  is 
to  be  done; 

3.  Object  Design.  During  this  phase,  the  object  relationship  model,  dynamic 
model,  and  fimctional  model  are  evaluated  to  determine  what  operations 
must  be  implemented  for  each  object.  Structures  for  representing  the 
relationships  between  objects  are  defined. 

4.  Implementation.  The  final  stage  involves  transforming  the  design  into  an 
executable  system.  This  is  dependent  on  whether  the  software  language 
selected  supports  object-oriented  programming. 

2.5  Conclusion 

This  literature  review  has  provided  an  overview  of  the  basic  concepts  of 
software  reengineering,  the  reengineering  of  relational  databases,  and  object-oriented 
methodology.  All  three  of  these  areas  are  required  for  the  successful  analysis  and 
implementation  of  the  new  methodology. 
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3  Methodology 


3.1  Introduction 

This  chapter  presents  the  methodology  for  reengineering  a  relational  database  to 
an  object-oriented  database.  It  shows  the  methodology  step  by  step  explaining  each 
step  in  detail,  including  some  discussion  of  typical  implementation  techniques  that  one 
can  find  during  the  process  of  reverse  engineering. 

This  methodology  is  based  on  Blaha  [1]  [2]  with  some  changes.  His  papers 
were  selected  because  they  are  focused  specifically  on  reverse  engineering  of  a 
relational  database  to  an  object-oriented  database  and  they  are  the  only  ones  that  give 
detailed  information  on  this  subject. 

Some  changes  were  introduced  on  his  approach  just  to  facilitate  the  transition 
from  relational  to  an  object-oriented  view.  The  most  important  changes  are: 

1.  Construct  an  entity-relationship  model  instead  of  going  directly  from  the 
tables  to  an  object  model; 

2.  Besides  the  object  model,  prepare  a  functional  model  to  facilitate  the 
implementation  of  the  system. 

3.2  The  Methodology 

This  methodology  is  presented  in  a  linear  fashion  for  ease  of  understanding, 
but,  except  for  the  first  and  last  step,  the  others  steps  are  weakly  ordered  since  during 
the  process  of  reverse  engineering  there  is  much  iteration  and  backtracking.  The  steps 
are  as  follows: 
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Step  1.  Prepare  an  entity-relationship  (ER)  model. 


This  step  can  be  easily  accomplished  by  using  an  automated  tool.  Otherwise 
proceed  as  listed  below: 

•  Represent  each  table  as  an  entity. 

•  Determine  candidate  keys.  Look  for  unique  indexes,  but  some  candidate 
keys  may  not  be  enforced  by  unique  indexes.  Automated  scanning  of  data 
can  yield  potential  candidate  keys. 

•  Determine  primary  keys.  Ordinarily  every  table  should  have  a  primary  key. 
But  exceptions  can  be  encountered  as  follow: 

1.  Tables  with  temporary  data  or  tables  which  the  performance 
overhead  can  not  be  tolerated. 

2.  Missing  primary  key  without  cause.  Some  applications  enforce 
primary  keys  with  custom  code  and  do  not  rely  upon  the  database 
manager. 

3.  Null  primary  key  attributes.  Some  relational  database  managers 
require  that  one  define  a  unique  index  to  enforce  a  primary  key. 
Indexed  attributes  are  permitted  to  be  null,  unless  “not  null”  is 
specified  for  each  of  the  attributes.  This  violates  the  definition  of 
primary  key;  attributes  in  a  primary  key  may  not  be  null. 
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4.  Extraneous  primary  key  attributes.  By  definition  a  primary  key  must 
also  be  minimal;  no  attribute  can  be  discarded  from  the  primary  key 
without  destroying  uniqueness.  The  reverse  engineer  must  regard  all 
primary  key  declarations  with  suspicion,  and  look  for  attributes  that 
do  not  seem  semantically  justified. 

Even  when  tables  do  have  a  primary  key,  different  realizations  may  still  be 
chosen.  Figure  2  shows  relational  tables  for  three  different  approaches  to 
identify  the  primary  key.  All  three  sehemas  can  be  reverse  engineered  to 
the  same  logical  model. 

•  Artificial  identity.  Each  object  table  (shown  in  Figure  2)  has  an 
object  identifier  as  primary  key.  Association  tables  (not  shown  in 
Figure  2)  have  a  primary  key  consisting  of  the  identifiers  of  the 
related  objects. 

•  Value-based  identity.  The  primary  key  of  each  object  consists  of 
some  eombination  of  applieation  attributes.  Some  primary  keys  may 
become  lengthy,  as  attributes  are  incorporated  from  foreign  key  of 
related  tables. 

•  Hybrid  identity.  One  may  use  artificial  identity  and  value-based 
identity  in  the  same  schema.  In  the  third  segment  of  Figure  2  Bank 
has  artificial  identity  and  Account  has  identity  derived  from  a 
reference  to  a  bank  eombined  with  an  aeeount  number. 
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Reverse  engineering  input:  Artificial  identity 


Bank 

Account 

bank  ID 

account  ID 

bank  name 

bank  ID 

account  number 

{Candidate  key  of  bank  is:  bank  name.} 

{Candidate  key  of  Account  is:  bank  ID  +  account  number.} 


Reverse  engineering  input:  Value-based  identity 


Bank 

Account 

bank  name 

bank  name 

account  number 

Reverse  engineering  input:  Hybrid  identity 


Bank 

Account 

bank  Id 

bank  ID 

bank  name 

account  number 

{Candidate  key  of  bank  is:  bank  name.} 


Reverse  engineering  output:  Logical  intent 


Figure  2:  Various  approaches  to  identify  the  primary  key  [2] 

•  Determine  foreign-keys.  Most  of  the  modern  RDBs  have  a  foreign-key 
clause  as  part  of  the  schema.  If  you  do  not  have  this  do  the  following: 

•  Try  to  resolve  homonyms,  attributes  with  the  same  name  that  refer  to 
different  things,  and  synonyms,  attributes  with  different  names  that 
refer  to  the  same  thing. 
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•  Matching  attribute  names,  data  types,  and/or  domains  suggest 
foreign  keys. 

•  Generate  the  relationships  by  checking  every  possible  foreign  key  against 
every  candidate  key. 

•  Finish  the  ER  model  by  querying  the  data  and  determining  the  multiplicity 
of  each  relationship. 

Step  2.  Prepare  an  initial  object  model. 

Based  on  the  ER  diagram,  represent  each  entity  as  a  tentative  class  and  each 
relationship  as  a  tentative  association.  All  columns  of  the  related  tables  become 
attributes  of  classes. 

Step  3.  Refine  tentative  classes. 

Agglomerate  horizontally  partitioned  classes  into  a  single  class.  Horizontally 
partitioned  classes  have  the  same  schema.  Distributed  databases  often  use  horizontal 
partitioning  to  disperse  records.  (Horizontally  partitioned  classes  must  also  have  the 
same  semantic  intent.  Identical  schema  is  a  good  indicator  of  same  semantic  intent.) 

Detect  functions  and  constraints  that  are  represented  as  tables  and  take  these 
classes  out  of  the  tentative  object  model.  Look  for  classes  that  do  not  participate  in  any 
foreign  key. 
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Step  4.  Discover  generalizations. 


Analyze  large  foreign-key  groups,  particularly  those  with  5,  10,  or  more  cross- 
related  attributes.  Look  for  a  primary  key  that  is  entirely  composed  of  a  foreign  key  of 
another  table.  Derived  identity  is  symptomatic  of  an  implementation  of  generalization 
with  distinct  superclass  and  subclass  tables  or  propagation  of  identity  via  one-to-one 
association.  Data  analysis  can  increase  confidence  in  the  discovery  of  generalization  by 
revealing  subsets  of  records. 

Look  for  patterns  of  many  replicated  attributes.  A  generalization  may  have 
been  implemented  by  pushing  superclass  attributes  down  to  each  subclass. 

Look  for  patterns  of  data  where  a  class  has  mutually  exclusive  subsets  of 
attributes.  This  may  indicate  an  implementation  of  generalization  where  subclass 
attributes  were  pushed  up  to  the  superclass. 

When  discovering  generalizations  one  must  not  forget  there  may  be  a  forest  of 
generalizations  with  multiple  superclass  roots  and  intermediate  levels.  Data  analysis 
can  help  distinguish  multiple,  disjoint,  and  overlapping  inheritance.  (Keep  in  mind  that 
data  analysis  only  yields  hypotheses,  and  semantic  understanding  is  required  to  reach 
firm  conclusions.) 

Step  5.  Discover  associations. 

Convert  a  tentative  class  to  an  association  when  a  candidate  key  is  a 
concatenation  of  two  or  more  foreign  keys.  Where  possible,  try  to  restate  ternary  and 
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n-ary  associations  (confluence  of  primary  keys  from  three  or  more  classes)  as  binary 
associations  [2] . 

Introduce  a  qualified  association  when  a  candidate  key  combines  a  foreign  key 
with  non-foreign  key  attributes.  This  will  find  some,  but  not  all,  qualifiers. 

The  remaining  associations  are  buried  and  manifest  as  foreign  keys. 

Note  minimum  multiplicity  for  associations.  Optional  multiplicity  (nulls 
allowed)  is  the  permissive  case  as  for  a  given  record  you  may  store  an  actual  value  or 
store  a  null;  a  lower  limit  of  one  (or  another  number)  is  more  restrictive. 

Note  maximum  multiplicity  for  associations.  Many  multiplicity  is  the 
permissive  case  as  a  collection  can  store  a  single  value  or  many  values;  an  upper  limit 
of  one  (or  another  number)  is  more  restrictive. 

Apply  semantic  understanding  and  restate  some  associations  as  aggregations. 
(Aggregation  is  the  “a-part-of”  relationship.) 

When  discovering  associations  be  aware  to  the  following  kind  of 
implementations  that  one  may  encounter  [2] : 

•  Double-buried  associations.  This  is  when  an  association  was  buried  in 
both  participating  classes  as  shown  in  Figure  3 .  This  construct  complicates 
reverse  engineering,  since  these  double-buried  associations  look  like  two 
separate  associations.  Data  analysis  can  detect  redundancy  between  the  dual 
pointers,  but  semantic  understanding  is  required  to  resolve  this  situation. 
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Model  as  implemented 


A  table 

B  table 

A  primary  kev 

B  foreign  key 
other  A  attributes 

1 

B  primary  kev 

A  foreign  key 
other  B  attributes 

Logical  intent 


Figure  3:  Double  buried  association 

•  Optional  qualified  association.  Figure  4  shows  an  optional  qualified 
association.  A  cluster  contains  many  Tables.  A  Table  may  belong  to  at 
most  one  Cluster.  The  combination  of  a  Cluster  and  a  table#  yields  a 
specific  Table.  This  association  was  implemented  by  burying  cluster _id  as  a 
foreign  key  in  Table.  Because  of  the  optional  membership  in  a  cluster,  the 
foreign  key  can  be  null,  and  the  combination  of  cluster Jd  and  table#  is  not 
a  candidate  key  of  Table.  Therefore  it  is  difficult  to  detect  this  qualified 
association. 

•  Alternate  qualifier.  In  Figure  5  Column  derives  its  identity  from  a  Table 
plus  a  qualifier,  either  column  name  or  column  number. 
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Model  as  implemented 


Cluster 


Table 

table# 


Logical  intent 


Cluster 

! 

table# 

- 

Table 

Figure  4:  Optional  qualified  association 


Model  as  implemented 


Column  table 

column  primary  key 
table  foreign  key 
column  name 
column  number 
other  column  attributes 


Table  table 

table  primary  key 
other  column  attributes 


{Candidate  key  of  Column  table  is; 

table  foreign  key  +  column  name, 
table  foreign  key  +  column  number.} 


Logical  intent 


Figure  5:  Alternate  qualifiers 

Step  6.  Perform  transformation. 

Various  optimizations  may  have  been  employed  in  preparing  the  original  RDB 
schema  to  improve  time  and/or  space  performance.  Some  transformations  are  listed 
here  [1]. 
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•  Convert  a  class  to  a  link  class  as  needed.  A  link  class  is  an  association 


whose  links  can  participate  in  associations  with  other  classes.  An 
association  has  derived,  rather  than  intrinsic,  identity. 

•  Lightweight  one-to-one  associations  (they  have  no  attributes)  should  be 
more  simply  represented  as  an  attribute.  For  example,  it  is  unnecessary  to 
represent  city  as  a  class,  when  city-name  is  the  only  attribute  of  interest. 

•  Nonatomic  n-ary  associations  should  be  decomposed  into  their  constituent 
associations  of  lesser  order.  Binary  associations  are  most  common  and 
easier  to  understand.  We  may  find  ternary  association,  but  never  an 
association  of  higher  order. 

•  Consider  shifting  associations  via  transitive  closure.  For  example 
associations  from  A  to  B  and  B  to  C  could  possibly  be  restated  as 
associations  from  A  to  B  and  A  to  C.  In  general,  multiplicity  constrains 
derivation  of  association,  but  the  vague  multiplicity  limits  often  obtained 
through  reverse  engineering  allow  more  latitude. 

•  Double-buried  associations  should  be  merged  into  a  single  association.  For 
example,  an  association  between  A  and  B  may  have  been  buried  in  both  the 
A  and  B  classes. 

•  You  may  need  to  insert  an  intermediate  class  in  a  generalization  hierarchy 
to  recognize  common  semantics,  attributes,  and  associations. 

•  Transitive  closure  also  arises  through  the  combination  of  generalization  and 
association.  Where  possible,  eliminate  an  imprecise  association  to  a 
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superclass  in  favor  of  a  more  restrictive  association  to  a  subclass.  For 


example,  in  Figure  6  if  our  semantic  knowledge  is  that  X  only  associates 
with  B  and  never  with  C,  then  we  can  eliminate  the  association  between  X 
and  A  and  the  association  between  X  and  C. 


Figure  6:  Transitive  closure  involving  generalization  and  association  [1] 

•  Similarly,  eliminate  associations  to  subclasses  by  recognizing  patterns  of 
commonality.  In  Figure  6,  if  all  instances  of  B  partition  across  classes  D 
and  E,  we  can  eliminate  the  association  between  X  and  D  and  the 
association  between  X  and  E. 

Step  7.  Prepare  a  functional  model. 

The  functional  model  describes  computations  within  a  system,  and  specifies  the 
results  of  this  computation  without  specifying  how  or  when  they  are  computed. 
Database  system  often  have  a  trivial  function  model,  since  their  purpose  is  to  store  and 
organize  data,  not  to  transform  it  [11:123]. 
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One  can  prepare  the  functional  model  only  using  the  user  manual,  the  forms, 
and,  if  necessary,  interviewing  the  users. 

3.3  Summary 

This  chapter  has  presented  the  methodology  for  reengineering  a  relational 
database  to  an  object-oriented  database.  This  methodology  is  heavily  based  on  Blaha 
papers  [1]  and  [2],  except  for  the  first  step,  that  was  introduced  to  facilitate  the 
transition  from  relational  to  an  object-oriented  view,  and  the  last  step,  that  was 
introduced  to  give  more  information  about  the  fimctionality  of  the  system.  It  showed 
each  step  to  be  followed  with  some  discussion  of  typical  implementation  techniques. 
The  next  chapter  presents  the  application  of  this  methodology  using  AFITSIS  as  a  test 
case. 
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4  Application  of  Methodology 


4.1  Introduction 

This  chapter  presents  the  application  of  the  proposed  methodology  using 
AFITSIS  as  a  test  case.  It  is  divided  into  three  sections:  the  first  section  shows  how 
the  ER  model  was  obtained.  The  next  section  presents  the  transformations  that  were 
made  to  the  ER  model  to  obtain  the  object  model.  The  last  section  shows  how  the 
functional  model  was  drawn. 

Following  direction  of  the  sponsor  (AFIT/SC),  this  analysis  is  restricted  to 
those  tables  and  forms  that  have  some  relationship  to  the  Person  table.  This  restriction 
does  not  invalidate  the  work,  since  about  66  of  294  tables  from  the  entire  AFITSIS  are 
considered. 

4.2  ER  Model 

To  accomplish  the  first  step  of  the  methodology,  which  is  to  draw  the  ER 
model,  we  used  ERwin  (an  ER  diagram  editor  developed  by  Logic  Works  [12]).  Since 
AFITSIS  was  developed  for  Oracle  version  5,  which  does  not  support  foreign-key 
clauses,  and  migrated  to  Oracle  version  6  without  changes,  ERwin  was  able  to  capture 
only  the  tables  and  its  attributes  (all  294  tables  from  AFITSIS).  If  you  are  reverse 
engineering  a  RDB  that  supports  foreign-key  clauses,  ERwin  can  recover  not  only  the 
tables  and  their  attributes,  but  also  foreign-keys,  the  relationships  between  tables,  and 
can  draw  the  entire  ER  model. 
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We  started  our  work  identifying  the  Person’s  primary  key  (SSAN).  Next  we 
selected  all  tables  that  have  this  primary  key  as  an  attribute  by  querying  the  Oracle  data 
dictionary  (Figure  7).  This  query  resulted  in  66  tables  (Appendix  A). 


SELECT  table_name 
FROM  accessible_coIumns 
WHERE  column_name 
like  “%SSAN%”; 


Figure  7:  SQL  statement  to  find  tables  with  SSAN  as  an  attribute 

The  next  step  was  to  determine  the  candidate  keys  for  each  of  the  selected 
tables.  We  looked  for  unique  indexes  in  the  data  dictionary,  and  for  each  one  that  we 
found  we  scanned  the  data  to  confirm  the  correctness.  For  the  other  tables  for  which 
we  could  not  find  a  unique  index,  we  had  to  scan  the  data. 

During  the  process  of  scanning  the  data  to  look  for  the  primary  key,  we  were 
able  to  find  many  tables  that  have  no  data,  tables  that  have  not  been  used  for  many 
years,  and  tables  that  were  used  as  a  temporary  files.  After  we  confirmed  that  they 
were  not  being  used  by  any  form,  we  eliminated  these  tables  from  our  diagram. 

We  looked  for  foreign  key  groups  by  matching  attribute  names  and  types.  We 
did  not  have  any  complication  in  this  step,  especially  because  the  names  are  very 
suggestive  and  we  did  not  find  any  homonyms  nor  synonyms. 

Next,  we  were  able  to  generate  the  relationships  between  the  entities  by 
checking  every  possible  foreign  key  against  every  candidate  key,  and  linking  the 
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related  entities  using  ERwin.  In  our  model  we  did  not  consider  as  a  relationship  the 
link  of  a  table  with  a  validation  table,  via  its  foreign  key.  For  example:  Address  table 
has  as  foreign  keys  the  attributes  Address Jype  code,  Street Jype_code, 
Address  room  type  code,  and  country  code-,  which  are  the  primary  key  of  the 
following  validation  tables  (table  look  up):  Addresstypevalid, 

Street_type_code_valid,  Addressroomtypecodevalid,  and  Countryvalid, 
respectively. 

To  finish  the  ER  model  (see  Appendix  B)  we  queried  the  data  to  determine  the 
multiplicity  of  each  relationship,  doing  the  following: 

•  One-to-one  association.  To  determine  a  one-to-one  association  we  verified 
if  for  each  row  in  one  table  of  the  relationship  there  was  only  one  entry  into 
the  other  table. 

•  One-to-one-or-more  association.  For  this  type  of  association  we  verified 
whether  for  each  row  in  one  table  we  found  at  least  one  or  more  entries 
into  the  other  table. 

•  One-to-zero-or-one  association.  In  this  case  we  verified  whether  for  each 
row  in  one  table  we  could  find  zero  or  exactly  one  entry  into  the  other 
table. 

•  One-to-zero-one-or-more  association.  Now  we  verified  whether  for  each 
row  in  one  table  we  found  zero  or  more  entries  into  the  other  table. 
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4.3  Object  Model 


To  draw  the  object  model  we  started  preparing  an  initial  objeet  diagram  (step  2) 
based  on  the  ER  diagram,  where  we  represented  eaeh  entity  as  a  tentative  class  and 
each  relationship  as  a  tentative  association.  We  transformed  all  colunms  of  the  related 
entity  into  the  attributes  of  the  class. 

We  started  refining  the  object  model  (step  3)  by  looking  for  horizontally 
partitioned  classes  (classes  with  the  same  schema)  and  representing  them  as  a  single 
class.  This  is  what  we  found: 

•  The  classes  Term  entry  and  Term  entry  history  had  the  same  schema  and 
the  same  semantic  intent.  We  merged  them  into  a  single  class; 

•  The  classes  Selectedjstudent,  Selected_student_91 ,  and 

Selected_student_new_91 ,  had  the  same  schema  but,  after  checking  the 
data,  we  determined  that  the  classes  Select ed_student_91  and 

Selected_student_new_91  were  used  as  temporary  files.  We  retained  only 
the  class  Selected _student  and  eliminated  the  others. 

Then  we  looked  for  tables  that  could  have  been  representing  functions  and/or 
constraints,  but  we  did  not  find  any. 

We  started  the  process  of  discovering  generalization  (step  4)  by  looking  for 
large  foreign-key  groups.  Although  we  found  a  couple  of  tables  in  this  case  we 
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realized  that  these  tables  were  not  involved  in  a  generalization  but  in  a  binary  or 
ternary  association. 

Generalization  was  found  when  we  started  looking  for  any  class  that  had  its 
primary  key  entirely  composed  of  a  foreign  key  of  another  class.  We  took  these 
classes  apart  and  analyzed  their  relationship. 

To  do  a  good  analysis  of  this  kind  of  relationship  we  had  to  improve  our 
semantic  knowledge  of  the  system.  We  did  that  by  making  some  queries  and  analyzing 
its  results,  by  looking  up  the  forms,  and  by  interviewing  the  Database  Administrator 
(DBA).  After  that,  we  were  able  to  take  these  classes  and  select  those  involved  in  a 
generalization  from  those  involved  in  an  association.  For  example:  the  tables 
Spousejnfo,  Emergency  _data,  AFITjiserjiame,  Recall _roster, 

Dependent Jnformation,  and  Graduationjiame  all  have  their  primary  key  entirely 
composed  of  Person’s  primary  key,  but  they  have  no  inheritance  relationship  with  this 
table. 

Semantic  knowledge  was  especially  important  to  incorporate  some  abstract 
classes.  For  example,  in  the  object  diagram  in  Figure  15  (Appendix  C),  the  abstract 
classes  Civilian  and  Military  were  introduced  after  we  discovered  that  Faculty,  Student, 
and  Administrative  people  could  be  either  military  or  civilian,  but  only  military  people 
have  a  relationship  with  Rank  history  and  Recall  roster.  So,  we  decided  to  introduce 
these  two  abstract  classes  to  increase  code  reuse  and  to  organize  features  common  to 
these  subclasses. 
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Another  generalization  chain  was  encountered  when  we  analyzed  Student, 
Cl  student.  Resident jtudent,  and  INTL  student  tables.  We  found  out  that  every 
instance  of  Cl  student  and  Resident  student  was  in  the  Student  table,  and  that  every 
instance  of  INTL  student  was  in  the  Resident  student  table. 

We  introduced  the  class  Part-time  student  to  represent  another  kind  of  student, 
after  we  discovered  that  this  class  was  implemented  as  an  attribute  of  Resident  student 
class  called  program  code.  One  of  the  valid  values  is  ‘PTE’,  meaning  ‘part-time 
student’. 

Data  analysis  was  very  important  to  increase  confidence  in  the  discovery  of 
generalization.  Figure  8  shows  our  initial  object  diagram  where  we  made  some 
assumptions  based  on  our  understanding  of  the  system.  But,  after  we  analyzed  the  data 
in  the  Eligible,  Selectedjstudents,  and  Student  tables,  we  discovered  that,  contrary  to 
our  assumption,  not  all  instances  of  Student  could  be  found  in  the  Selected  student 
table,  and  that  not  all  instances  of  Selected  student  could  be  found  in  the  Eligible  table. 
This  data  analysis  led  us  to  change  our  object  diagram  to  the  one  shown  in  Appendix 
C. 

We  continued  our  work  of  drawing  the  object  model  by  discovering  other 
associations  (step  5).  We  started  this  step  by  looking  for  candidate  keys  composed  of 
two  or  more  foreign  keys,  and  we  converted  it  into  an  association.  Figure  9  shows  one 
binary  association  that  we  found.  All  the  other  associations  can  be  seen  in  Appendix 
C. 
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Figure  8:  Initial  object  diagram  before  the  data  analysis 


Figure  9:  Binary  association 


34 


We  introduced  a  qualified  association  when  we  found  a  candidate  key  that 
combined  a  foreign  key  with  a  non-foreign  key  attribute.  Figure  10  shows  some  of  the 
qualified  associations  that  we  introduced  to  reduce  the  effective  multiplicity  of  the 
association  (from  many  to  one),  to  improve  semantic  accuracy,  and  to  increase  the 
visibility  of  navigation  paths. 


Figure  10:  Qualified  associations 


In  our  research  we  were  not  able  to  find  the  following  cases  of  association: 


•  Association  that  could  be  representing  an  aggregation; 


•  Double-buried  associations; 


•  Optional  qualified  association; 
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Alternate  qualifier. 


We  started  our  final  step  (step  6-perform  transformation)  to  get  the  object  model 
by  transforming  each  lightweight  one-to-one  association  into  an  attribute.  We  found  a 
one-to-one  association  of  Person  with  AFIT  user  name  and  Person  with 
Emergency jdata  and  we  transformed  these  associations  into  attributes  of  Person 
(Person  Structure  Definition,  Appendix  C).  We  did  the  same  with  a  one-to-one 
association  of  Resident  student  with  Graduation  name  (see  Resident  Student  Structure 
Definition,  Appendix  C). 

We  did  not  find  any  class  that  could  be  better  represented  as  a  link  class.  This 
does  not  mean  that  none  of  our  classes  is  a  link  class;  the  only  restriction  is  that  our 
view  is  limited,  since  our  research  is  concerned  with  only  part  of  AFITSIS.  We  did 
not  have  to  do  any  work  to  decompose  n-ary  associations  into  their  constituent 
associations  of  lesser  order,  especially  because  we  had  only  binary  associations.  Our 
complete  object  model,  including  the  object  structure  definition,  can  be  seen  in 
Appendix  C. 

4.4  Functional  Model 

In  order  to  get  the  functional  model  done  we  initially  made  use  of  the  STARS 
User’s  Guide  [3]  to  select  the  boundaries  of  what  we  were  going  to  implement,  and 
then  limited  our  work  in  doing  the  functional  model  to  this  specific  part.  We  used 
SQLForms  to  extract  the  name  of  the  tables  that  each  form  can  read  or  update,  what 
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actions  the  form  is  doing,  and  all  the  other  information  needed  to  draw  the  functional 
model.  The  complete  funetional  model  is  shown  in  Appendix  D. 

4.5  Summary 

This  chapter  has  presented  the  application  of  the  proposed  methodology  using 
AFITSIS  as  a  test  case.  It  showed  how  the  ER  model  was  obtained,  the 
transformations  that  were  made  on  the  ER  model  to  get  the  object  model,  and  how  the 
functional  model  was  drawn.  The  next  chapter  discusses  the  implementation  of  part  of 
AEITSIS  using  an  OODBMS. 
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5  Implementation  Issues 


5.1  Introduction 

This  chapter  presents  the  implementation  issues  concerning  the  development  of 
part  of  AFITSIS  using  an  OODBMS.  It  is  divided  into  three  seetions:  the  first  section 
discusses  how  we  analyzed  several  OODBMS  and  why  we  ehose  Mierosoft  Visual 
Foxpro  (Foxpro)  version  3  to  be  used  in  this  implementation.  The  next  section  shows 
how  part  of  the  objeet  model  was  implemented.  The  last  section  discusses  some 
limitations  encountered  when  using  Foxpro  as  an  OODBMS. 

5.2  Analysis  and  Choice  of  the  OODBMS 

During  the  process  of  choosing  one  OODBMS  to  implement  part  of  AFITSIS 
we  took  the  following  considerations: 

•  Based  on  the  interview  [4],  AFIT/SC  wanted  to  migrate  AFITSIS  to  an 
OODBMS.  However,  before  making  any  decision,  they  will  wait  for  Oraele 
Company  to  release  version  8,  expected  to  be  an  extension  of  the  RDBMS 
with  some  object  capabilities; 

•  Since  Oracle  version  8  is  not  expeeted  to  reach  the  market  until  the  end  of 
1996  or  begiiming  of  1997,  and  with  the  intention  of  doing  a  useful 
implementation,  we  looked  for  an  available  RDBMS  that  would  have  some 
similarities  with  the  expeeted  Oraele  version  8.  These  similarities  that  we 
were  concerned  about  are:  the  product  should  be  able  to  use  all  the  power 
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and  flexibility  of  RDBMS,  like  Data  Definition  Language  (DDL)  and  Data 
Manipulation  Language  (DML),  share  the  basic  relational  tables,  and 
incorporate  some  concept  of  “object,”  and  have  the  ability  to  store 
procedures  as  well  as  data  in  the  database. 

With  these  considerations  in  mind  we  started  analyzing  some  available 
OODBMS.  The  first  two  OODBMS  that  we  analyzed  were  ITASCA  and  Objectstore. 
Even  though  we  concluded  that  each  is  a  very  good  OODBMS,  we  decided  not  to  use 
either  of  them  because  they  are  heavily  based  on  some  language  like  C  or  C  +  + ,  and 
they  have  no  compatibility  and  similarity  with  any  RDBMS. 

The  next  product  that  we  analyzed  was  Foxpro.  Once  we  had  some  experience 
in  using  an  old  version  of  Foxpro  and  knowing  that  it  is  a  RDBMS,  we  concentrated 
our  analysis  to  see  if  the  new  object-oriented  features  would  be  compatible  with  what 
we  wanted.  After  we  read  the  Foxpro  Developer’s  Guide  [13]  and  used  it  for  two 
weeks,  we  were  convinced  that  this  product  could  give  us  a  good  means  of  comparison 
and  insight  of  what  we  could  expect  when  we  have  the  Oracle  version  8  available. 

5.3  Implementation  of  the  Object  Model 

We  started  the  implementation  of  our  object  model  by  creating  a  new  project 
and  inserting  a  new  database  that  we  called  Stars.  In  Foxpro  the  terms  database  and 
table  are  not  synonymous.  The  term  database  refers  to  a  relational  database  that  stores 
information  about  one  or  more  tables  or  views  [13].  The  database  is  where  we  can 


39 


create  stored  procedures  (that  can  be  used  as  field-  and  record-level  rules)  and 
persistent  table  relationships  (to  enforce  referential  integrity). 

After  we  created  the  Stars  database  we  created  the  definition  of  the  tables  that 
we  were  going  to  use,  their  primary  key  and  indexes,  and  we  added  these  tables  to  the 
database.  Then  we  linked  the  tables  to  set  up  the  relationships  (Figure  33,  Appendix 
E),  so  that  we  do  not  need  a  code  program  to  check  the  referential  integrity  every  time 
an  application  tries  to  modify  the  database.  The  database  manager  system  takes  care  of 
it  whenever  the  database  is  opened  and  used. 

The  next  step  was  to  create  the  forms,  one  for  each  table.  After  that,  we  were 
ready  to  start  creating  the  definitions  of  the  classes.  To  implement  the  Person’s  Object 
Model  (Figure  15,  Appendix  C)  we  did  the  following: 

•  We  created  the  Verson’s  class  based  on  the  Verson’ s  form  (Figure  34, 
Appendix  E); 

•  We  created  the  Military’s  class  based  on  the  Person’s  class  and  adding  the 
Military’s  form  (Eigure  35,  Appendix  E); 

•  We  created  the  Military  student’s  class  based  on  the  Military’s  class  and 
adding  the  Student’s  form  (Figure  36,  Appendix  E); 

•  We  created  the  Military Jdculty’s  class  based  on  the  Military’s  class  and 
adding  the  Faculty ’s  form; 
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•  We  created  the  Military  resident  student’s  class  based  on  the 

Military _student’s  class  and  adding  the  Resident  student’s  form  (Figure  37, 
Appendix  E); 

•  We  created  the  Military _INTL  student’s  class  based  on  the 

Military  Resident  student’s  class  and  adding  the  INTL  student’s  form 
(Figure  38,  Appendix  E); 

•  We  created  the  Civilian’s  class  based  on  the  Person’s  class  and  adding  the 
Civilian’s  form  (Figure  39,  Appendix  E); 

•  We  created  the  Civilianjstudent’s  class  based  on  the  Civilian’s  class  and 
adding  the  Student’s  form  (Figure  40,  Appendix  E); 

•  We  created  the  Civilian Jaculty’s  class  based  on  the  Civilian’s  class  and 
adding  the  Faculty ’s  form; 

•  We  created  the  Civilian  resident  student’s  class  based  on  the 

Civilianjstudent’s  class  and  adding  the  Resident  student’s  form  (Figure  41, 
Appendix  E); 

•  We  created  the  CivilianINTLstudent’s  class  based  on  the 

Civilian  resident  student’s  class  and  adding  the  INTL  student’s  form  (Figure 
42,  Appendix  E); 

The  reason  we  created  the  classes  this  way  was  to  give  more  flexibility  and  to 
make  the  classes  easier  to  maintain.  For  example:  if  we  need  to  make  some  change  in 
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person ’s  class  we  do  not  have  to  modify  all  the  other  classes  that  use  it.  Because  of  the 
inheritance  feature,  the  changes  that  we  make  in  the  parent  class  reflect  over  the 
subclasses  automatically;  and  if  we  need  to  overload  some  parent  method  (function, 
procedure,  trigger,  or  event)  so  that  it  takes  a  different  action  when  running  the 
subclass,  it  can  be  easily  achieved  by  just  creating  a  method  in  the  subclass  with  the 
same  name  as  the  parent  class.  This  way  the  subclass  method  will  have  precedence 
over  the  parent  class  method. 

We  implemented  binary  associations  by  first  creating  a  view  with  the  related 
tables  and  then  creating  a  form  based  on  this  view.  For  example:  the  association 
between  Person  and  Address  (Figure  16,  Appendix  C)  was  implemented  by  creating  a 
view  with  Person  and  Address  tables,  and  then  creating  a  form  using  this  view,  the 
Person  class,  and  the  Address  form  (Figure  43,  Appendix  E). 

We  implemented  a  binary  association  with  link  attributes  by  creating  a  new 
table  with  these  link  attributes  and  the  primary  key  of  the  two  associated  tables  as 
foreign  keys.  We  created  a  form  based  on  this  new  table,  and  a  class  based  on  this 
form.  For  example:  the  Dropped  Courses  Association  (Figure  22,  Appendix  C)  was 
implemented  by  creating  a  Dropped  courses  table  having  the  primary  key  of  the 
Course  and  Resident  student  tables  as  foreign  keys,  plus  the  link  attributes.  Then  we 
created  a  form  base  on  the  Dropped  courses  table  and  a  class  Dropped  courses  based 
on  this  form. 
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5.4  Limitations  of  Foxpro  Encountered  During  Implementation 


During  the  implementation  of  our  object  model  we  faced  two  major  problems 
when  using  Foxpro  as  an  OODBMS.  The  first  one  is  that  in  Foxpro  we  can’t  define 
one  class  based  on  a  table  by  only  adding  its  methods.  Instead,  we  have  to  define  the 
table,  define  one  form  based  on  this  table,  and  then  define  the  class  based  on  this  form 
and  add  the  methods.  Actually,  this  peculiarity  does  not  cause  much  of  a  problem 
(when  you  need  to  modify  some  attribute,  you  have  to  change  the  table  structure  and  its 
related  form),  but  it  is  a  little  different  from  what  we  learned  in  theory  [11]. 

Another  problem  encountered  is  that  Foxpro  did  not  appear  to  support  multiple 
inheritance.  To  implement  the  Person’s  Object  Model  (Figure  15,  Appendix  C), 
instead  of  defining  only  one  class  for  Student,  Faculty,  and  Administrative,  we  had  to 
define  the  classes  Military  jstudent.  Military  Jdculty  Military  _administrative. 
Civilian _student.  Civilian Jaculty ,  Civilian_administrative,  and  so  on.  This  restriction 
may  cause  some  problems  if  the  subclass  has  other  relationships.  For  example:  the 
relationship  Advises  between  Faculty  and  Resident  student  (Figure  15,  Appendix  C), 
has  to  be  implemented  by  defining  one  relationship  Advises  from  Civilian _faculty  to 
Civilian_resident_student  and  Military  resident  student,  and  the  same  relationship 
Advises  from  Military  Jaculty  to  Civilian  resident  student  and 

Military  _resident_student. 
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5.5  Summary 


This  chapter  has  presented  the  implementation  issues  of  part  of  AFITSIS.  Some 
OODBMS  were  analyzed  and  Foxpro  was  chosen  because  of  its  similarity  to  what  we 
are  expecting  for  Oracle  version  8.  We  showed  the  implementation  teehniques  that  we 
used  to  implement  inheritance  and  some  associations.  During  the  implementation  we 
found  two  limitations  in  using  Foxpro  as  an  OODBMS.  One  is  that  we  can’t  define  a 
class  directly  from  a  table  and  the  other  is  that  it  does  not  support  multiple  inheritance. 
With  this  implementation  done,  we  had  the  last  pieee  of  information  necessary  to  make 
an  analysis  and  eonclusion  of  our  research.  That  is  presented  in  the  next  chapter. 
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6  Analysis,  Conclusions,  and  Recommendations 


6.1  Analysis  of  The  Results 

In  Chapter  III  we  presented  a  methodology  for  reengineering  a  relational 
database  to  an  object-oriented  database.  To  validate  this  methodology  we  applied  it  to 
reengineering  AFITSIS  as  a  test  case.  As  we  presented  in  Chapter  IV,  this 
methodology  is  easy  to  use  in  practice.  We  did  not  have  any  difficulty  when  following 
its  steps. 

Our  methodology  has  the  purpose  of  reengineering  a  relational  database, 
independent  of  the  kind  of  the  RDBMS  and  its  version.  With  our  test  case,  we  had  the 
opportunity  to  verify  this  applicability,  especially  because  AFITSIS  comes  from  an  old 
version  of  Oracle  RDBMS.  This  way  we  could  apply  most  of  the  steps  of  what  we 
proposed  in  the  methodology.  For  example:  to  accomplish  the  first  step  of  the 
methodology,  which  is  to  draw  the  ER  model,  we  used  ERwin.  Since  AFITSIS  was 
developed  for  Oracle  version  5,  which  does  not  support  foreign-key  clauses,  ERwin 
was  able  to  capture  only  the  tables  and  their  attributes.  Since  ERwin  was  not  able  to 
draw  the  entire  ER  model  and  facilitate  this  job,  we  really  had  to  apply  the 
methodology  and  follow  its  steps  to  recover  the  foreign-keys  and  the  relationships 
between  tables. 

When  applying  our  methodology  to  draw  the  object  model  we  found  out  that 
semantic  logic  can  play  an  important  role,  especially  to  discover  generalization  and  to 
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incorporate  some  abstract  classes.  Another  important  factor  that  we  found  that 
increased  our  confidence  in  the  discovery  of  generalization  was  data  analysis.  After  we 
analyzed  the  data  we  could  change  our  first  object  diagram  to  the  one  shown  in 
Appendix  C.  Even  though  in  our  test  case  we  were  not  able  to  apply  our  methodology 
to  exemplify  the  discovery  of  all  kinds  of  associations,  we  were  able  to  find  some  of 
them. 

The  most  important  result  of  this  analysis  is  that  it  demonstrated  that  the 
proposed  methodology  can  be  easily  used  for  reengineering  any  relational  database  to 
an  object-oriented  database,  filling  the  lack  of  a  robust  process  that  can  be  applied  in  all 
cases. 

6.2  Conclusion 

The  life  span  of  an  information  system  consists  of  specification,  design  and 
maintenance.  The  maintenance  phase  dominates  in  time  and  often  with  respect  to 
resources  as  well.  During  this  phase  the  system  is  subjected  to  a  number  of  changes 
and  additions.  The  gap  between  the  older  technology  in  the  system  and  the  new 
technology  that  becomes  available  increases  successively.  Changes  in  the  activities  of 
an  organization  also  mean  that  systems  grow  old. 

Gradually  the  system  approaches  a  limit  where  it  no  longer  is  cost-efficient  or 
even  technically  feasible  to  continue  the  maintenance.  But  the  cost  of  enforcing  the 
required  changes  is  usually  very  high  [8].  A  possible  way  out  of  this  dilemma  is  to 
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define  well  delimited  system  parts  that  are  candidates  for  modernization.  This  is  where 
reengineering  can  help. 

We  have  described  a  practical  method  for  reengineering.  The  method  is  based 
on  object-oriented  modeling.  We  have  described  how  the  work  can  be  divided  into  a 
number  of  steps  so  that  the  method  can  be  performed  in  a  systematic  marmer. 

We  have  used  AFITSIS  as  a  test  case  and  have  shown  that  with  this  method  we 
can  model  an  existing  system  in  a  simple  manner  and  with  limited  effort.  The  new 
model  is  object-oriented  and  can  serve  as  a  basis  for  a  fumre  development  plan. 

We  have  implemented  part  of  AFITSIS  using  Foxpro,  one  OODBMS  that  we 
have  chosen  because  of  its  similarities  with  the  expected  Version  8  of  Oracle.  From 
this  experience  we  were  able  to  see  that  our  object  model  can  be  easily  mapped  to  be 
implemented  using  another  OODBMS. 

The  six  research  objectives,  as  stated  in  Chapter  I,  were: 

1.  Define  an  appropriate  reverse-engineering  methodology; 

2.  Determine  an  appropriate  database  application  to  be  a  test  case; 

3.  Analyze  and  reverse  engineer  the  test  case  using  this  methodology; 

4.  Redesign  the  test  case  using  object-oriented  methods; 

5.  Implement  a  portion  of  the  new  design  in  an  Object-Oriented  Database 
Management  System  prototype  system; 

6.  Analyze  the  methodology  based  on  this  experience. 
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The  research  was  successful  in  all  the  original  objectives.  We  presented  a 
practical  methodology  that  can  be  applied  for  reengineering  any  relational  database 
system.  We  chose  AFITSIS  as  a  test  case,  we  applied  our  methodology  for 
reengineering  it,  we  obtained  an  object  and  functional  model  from  this  work,  and  we 
implemented  this  model  using  an  OODBMS.  Finally,  one  of  the  most  important 
lessons  that  we  have  learned  when  working  with  reengineering  is  that  in  general,  the 
mapping  between  object  models  and  schemes  are  many-to-many.  Various  optimizations 
and  design  decisions  can  be  used  to  transform  an  object  model  into  a  database  schema. 
Similarly,  when  reverse-engineering  a  database,  alternate  interpretations  of  the 
strucmre  and  data  can  yield  different  object  models.  Usually,  there  is  no  obvious, 
single  correct  answer  for  reverse  engineering.  Multiple  interpretations  can  yield 
plausible  results  [1]. 

6.3  Recommendations 

For  those  who  intend  to  use  the  object  model  obtained  from  our  test  case,  we 
recommend  that  you  revise  this  model  making  another  data  analysis.  This  is  because 
we  had  restricted  access  to  AFITSIS  tables,  since  they  record  confidential  information. 
Doing  this  you  can  have  more  confidence  on  the  model,  and  may  find  some  important 
information  that  we  were  not  able  to  uncover. 

Even  though  Foxpro  was  demonstrated  to  be  a  good  OODBMS  to  be  used  in 
our  test  case,  I  recommend  further  analysis  concerning  its  security  of  the  data.  This  is 
because  security  is  an  important  aspect  to  be  considered  for  adopting  an  OODBMS  to 


48 


implement  AFITSIS,  and  Foxpro  does  not  appear  to  have  any  mechanism  to  restrict  the 
access  to  the  databases  (for  example:  password  with  level  of  access.) 
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Appendix  A:  List  of  Tables  with  SSAN 


(Pk):  Primary  key;  (Fk):  Foreign  key. 


Address:  SSAN  (Pk)  (Fk),  Address_Type_Code  (Pk),  Address_Line_l,  Address_Line_2,  Address_Line_3, 
City,  State  Code,  Zipcode,  Zipcode  Extension,  Country  Code,  Area  Code,  Phone_Number, 
Address  Effective  Date,  DSN  Prefix,  Login  Name,  Firm_Name_Office_Symbol, 

Additional  Address  Information,  Street  Address,  Street_Type_Code, 

Address_Room_Type_Code,  Address  Room  Type  Number,  Revision  Name,  Revision_Date, 
Country,  Login_Date,  Phone  Number  Ext. 

Address_Data_Final:  SSAN  (Pk)  (Fk),  Address  Type  Code  (Pk),Firm_Name_Office_Symbol, 
Additional_Address_Infonnation,  Street_Address,  City,  State  Code,  Zipcode, 

Zipcode  Extension,  Street  Type  Code,  Address_Room_Type_Code, 
Address_Room_Type_Number,  Area_Code,  Phone_Number,  Address_Effective_Date, 
DSN_Prefix,  Login_Name,  Revision  Name,  Revision  Date,  Country. 

AFITnet_User_Name:  SSAN  (Pk)  (Fk),  Login_Name,  Input_Date,  User_Name,  User_UID, 
Host_Accnt_Created 

Ci_Student:  SSAN  (Pk)  (Fk),  MajorOOcareer_Pointer_Code,  Academic_Status_Code, 

Accountmg_Status_Code,  Book  Payment  Authorize  Code,  Ci  Student  Comment, 
Civilian_Institution_Code,  Corps_Code,  Course_Of_Study,  CurrentOOASC_Code, 
CurrentOOewi_Option_Code,  Email_Address,  Grad_Date,  Gre_Status_Code, 

Hpsp_Medical_Code,  Ida_Date,  Kit_Sent_Date,  MAJCOM_Abbrev,  MajorOOASC_Code, 
Motorcycle_Status_Code,  MotorcycIe_Train_Date,  Office_Code  ,  Overseas_Indicator, 
Program_Entry_Date,  Quota_Program_Code,  Report_N o_Earlier_Than_Date, 
Report_No_Later_Than_Date,  ResidenceOOstate_Code,  Residency_Status_Code, 
SelectedOOASC_Code,  SelectedOOcareer_Pointer_Code,  SelectedOOewi_Option_Code, 
Selected_Date,  Selected  Quota  Year,  Thesis_Diss_Required_Code, 
Thesis_Program_Complete_Date,  Type_Degree_Code,  Input_Date,  Login  Name, 
EwiOOoccupation_Series_Code,  Scholarship  Type  Code,  DLI_Language_Code, 
Af_Acad_Sponsor_Dept_Code,  No  Cost  Indicator,  Esp_Code,  Book_Qtrs_Paid, 

DLI  Entry  Date,  School_In_Civ_Ins_Code,  Remarks,  Advance  Flag. 

Class_Leader:  SSAN  (Pk)  (Fk),  Leader  Code  (Pk),  Program  GraduationOOTerm  Code,  Class  Code, 
Program_Y  earPrefix. 

Degree_A wards:  AFIT  Degree  Code  (Pk)  ,  SSAN  (Pk)  (Fk),  Career  Pointer  Code,  Grad  Status  Code, 
Pse_Code,  Grade_Rank_Abbrev,  Name  Prefix,  Name_Suffix,  First  Name  ,  Last  Name  , 

Middle  lnitial,  Birth  Date,  Sex  Code,  Race  Code,  Marital  Status  Code,  Religion  Code, 
Blue_Chip_Indicator,  Aka  Fname,  Aka  Lname,  Prior_AFIT_Months,  Tafms  Date, 

Ethnic  Group  Code,  Aero  Rating  Code,  Manning  Code,  Deros  Date,  Separation  Date, 
Commission_Code,  Grade  Rank  Date,  CitizenshipOOcountry  Code,  Department  Code, 

Duty  Title,  Duty  Phone,  Duty_Area_Code,  Badge  Number,  Academic  Action  Code, 

Overdue  indicator,  Classification  Code,  Part_Record_Indicator,  Admin  Hold  Indicator, 
MajorOOASC  Code,  Academic_Specialty,  MajorOOed  Level  Code,  Ed  Level,  Program  Code, 
Program,  Program  GraduationOOterm  Code,  Class  Code,  Program  Year  Prefix, 

Selected  Type  Code,  Selected_Type,  AFIT_Degree,  GraduationOOterm  Code, 
GraduationOOquarter  Code,  Graduation  Year  Prefix,  Graduation  Date,  Departure  Date, 
Box_Number,  Card_Number,  Encoded  Card  Number,  Library  Number,  Locker  Number, 

Admit  Date,  Student  Sponsor  SSAN,  EntryOOterm_Code,  EntryOOquarter_Code, 

Entry  Year  Prefix,  Admission_Type_Code,  Admission  Action  Code,  GainingOOAFSC  Code, 
Faculty  Advisor  SSAN,  RegistrationOOdepartment  Code,  Program_EffectiveOOterm_Code, 
EffectiveOOquarter  Code,  Effective  Year  Prefix,  Leader_Code,  Program_Section_Number, 
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GainOOMAJCOM  Abbrev,  GainOOduty  Station,  LosingOOMAJCOM  Abbrev, 

Double  Degree  Indicator,  Branch  Service  Code. 

Dependent_Children:  SSAN  (Pk)  (Fk),  Child  Last  Name  (Pk),  Child  First  Name  (Pk), 
Dependent_Child_Birth_Date,  Dependent  At  AFIT  Indicator,  ChildOOsex  Code . 

Dependent_Information:  SSAN  (Pk)  (Fk),  Number  Children,  Sngle_Dep_Chldrti_Indicator, 
Deps_At_AFIT_Indicator. 

Drop_Table:  Course  Prefix  Code  (Pk)  (Fk),  Course  Number  (Pk)  (Fk),  Course  Section  (Pk)  (Fk),  SSAN 
(Pk)  (Fk),  Course_Dropped_Date,  Drop_Reason. 

Edplan_Desc:  Career_Pointer_Code  (Pk),  SSAN  (Pk)  (Fk),  Description,  Description  Line  Number. 

Education_History:  MPC  School  Code  (Pk)  (Fk),  Ed_Level_Code  (Pk),  SSAN  (Pk)  (Fk), 

Type  Degree  Code,  ASC  Code,  Quality  Points,  Total  Credit  Hours, 
Method_Of_Obtainment_Code,  Academic_Ed_Status_Code,  Input  Date,  Operators  initials, 
Login  Name,  Last  Year  Attended,  ABET_Accredited_Indicator,  Ed  History  Remarks, 

Work  ID  Processed  Code,  TmscrptOOcareer_Pointer_Code,  Duty  Location  Code, 

Degree  Cum  Gpa,  Degree  Title. 

Eligibility:  SSAN  (Pk)  (Fk),  EligibiIity_Evaluation_date  (Pk),  Pre_AFlTOOEd_Level_Code  (Pk), 
Counse;or_Initials,  Elig  Overall  GPA,  Elig  Math  GPA,  Elig,Major_GPA, 
Evaluatlon_Status_Code,  Llst_Number. 

Emergency_Data:  SSAN  (Pk)  (Fk),  Emergency_Contact_Fname,  Emergency_Contact_Lname, 

Emergency_Relation,  Address_Line_l,  Address_Line_2,  Address_Line_3,  City,  State_Code, 
Zipcode,  Zipcode_Extension,  Country_Code,  Area_Code,  Phone  Number,  Country, 
Firm_Name_Office_Symbol,  Additional_Address_lnformation,  Street_Address, 
Address_Room_Type_Code,  Address_Room_Type_Number,  Street_Type_Code, 

Revision_Name,  Revision_Date,  Login_Name,  Login_Date. 

EN_Program_Leader:  SSAN  (Pk)  (Fk),ENOOLeader_Code,  EN_StudentOOPrograni_Code, 
Program_Graduation_Term_Code,  Class_Code,  Program_Year_Prefix. 

Evaluation_By_School;  SSAN  (Pk)  (Fk),  Admitted_Indicator,  Evaluation_Result_Remark, 

Evaluation_Forwarded_Date,  Forwarded_ToOODepartment_Code,  Evaluation_Retumed_Date. 

Faculty:  SSAN  (Pk)  (Fk),  AFlT_School_Code,  Academic_Instruction_Indicator, 
Appointment_Type_Remark,  Faculty_Type_Code. 

Faculty_History:  SSAN  (Pk)  (Fk),  Academic_Rank_Code  (Pk),  Academic_Rank_Date,  Academic_Step. 

Fitness_Perforniance:  SSAN  (Pk)  (Fk),  Fitness_Category_Code(Pk),  Elapsed_Time,  Trial_Time, 

Input  Date,  Login  Name,  Distance. 

Grade_Change_History:  Course  Prefix  Code  (Pk)  (Fk),  Course  Number  (Pk)  (Fk),  Course_Section  (Pk) 
(Fk),  SSAN  (Pk)  (Fk),  Term_Code,  Grade  Effective  Date,  PriorOOgrade_Code. 

Grade_History:  Course  Prefix  Code  (Pk)  (Fk),  Course  Number  (Pk)  (Fk),  Course  Section  (Pk)  (Fk), 
SSAN  (Pk)  (Fk),  Term  Code,  Approval  Code,  Approval  Date,  Career  Pointer  Code, 

Credit  Hours,  Eamed  Hours  Indicator,  Gpa  indicator,  Grade  Code,  Grade_Effective_Date, 
Login  Name,  Grade  Type  Code,  Input  Date,  PriorOOgrade  Code. 

Graduation_Attendees:  SSAN  (Pk)  (Fk),  GraduationOOterm  Code  (Pk),  GraduationOOquarter  Code, 
GraduationY  earPrefix. 

Graduation_Date_History:  SSAN  (Pk)  (Fk),  GraduationOOterm  Code,  EffectiveOOterm  Code, 

Grad_Status_Code,  Departure  Date,  GraduationOOquarter_Code,  Graduation  Year  Prefix, 
EffectiveOOquarter  Code,  Effective  Year  Prefix,  Login_Name,  Input  Date. 

Graduation_Name:  SSAN  (Pk)  (Fk),  Graduation  Name. 

Intl_Student:  SSAN  (Pk)  (Fk),  WSCN,  ITO,  Case  Number,  DLI_Req_Indicator,  DLI  Indicator, 
Evaluation_Request_Date,  RequestedOOprogram_Code,  Eval  Forward  Date, 

Forward  ToOOdepartment  Code,  Eval_Retumed_Date,  Admission  Status  Code,  Eval  Remarks, 
Country  Notified  Date,  AFSAT  Notified  Date,  AFSAT_Quota_Indicator,  First_Sponsor_SSAN, 
Second  Sponsor  SSAN,  Source  Of  Funds  Code,  AFSAT  Country  Code. 

IP_Attendee:  SSAN  (Pk)  (Fk),  IP  Activity  Code  (Pk),  Activity  Date  (Pk). 

Languages  Spoken:  SSAN  (Pk)  (Fk),  Language  Code  (Pk). 

LS_Part_Time;  SSAN  (Pk)  (Fk),  PT_LS_StudentOOProgram_Code  (Pk). 

LS_Section_Leader:  SSAN  (Pk)  (Fk),  Section_Number  (Pk),  LSOOLeader  Code  (Pk). 
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Majors:  Career  Pointer  Code  (Pk),  Major  (Pk),  SSAN  (Pk)  (Fk),  Login  Name,  Input_Date. 

Name_History:  SSAN  (Pk)  (Fk),  Name_Change_Date  (Pk),  First_Name,  Last  Name,  Middle  lnitial, 
NameSuffix,  NamePrefix,  LoginName,  MaritalStatusCode. 

New_AFSC:  SSAN  (Pk)  (Fk),  AFSC_Code  (Pk),  Prefix. 

OER  Data:  SSAN  (Pk)  (Fk),  Last  OER  Date,  OER  Due  Date. 

PCE_Grade;  SSAN  (Pk)  (Fk),  PCE  Couse  Prefix  (Pk),  PCE  Couse  Number  (Pk),  PCE  Couse  Letter 
(Pk),  PCE  Couse  Year,  PCEOOGrade  Code. 

PCE_Std:  SSAN  (Pk)  (Fk),  PCE  Stay  Begin  Date  (Pk),  PCE_Stay_End_Date,  PCEOOBilleting  Code, 
MAJCOMCode. 

Person:  SSAN  (Pk),  Grade  Rank  Abbrev,  Name  Prefix,  Name  Suffix,  First  Name  ,  Last  Name  , 

Middle  lnitial,  Birth  Date,  Sex  Code,  Race  Code,  Marital  Status  Code,  Religion  Code, 
Blue_Chip_Indicator,  Aka  Fname,  Aka  Lname,  Prior_AFIT_Months,  Tafins  Date, 
Ethnic_Group_Code,  Aero_Rating_Code,  Manning  Code,  Deros  Date,  Separation  Date, 
Commission_Code,  Grade_Rank_Date,  CitizenshipOOcountry  Code,  Department_Code  , 
Duty_Title,  Duty_Phone,  Duty_Area_Code,  Badge  Number,  Branch  Service  Code, 

Logln_Name,  Input_Date,  Duty  Phone  Ext. 

Personnel:  SSAN  (Pk)  (Fk),  PersonnelOODepartment  Code,  Personnel  Hire  Date,  Personnel_Duty_Title, 
PhoneN umber. 

PHD:  SSAN  (Pk)  (Fk),  PHD_Major_Remark,  PHD  Minor  Remark. 

Planes_Flown:  SSAN  (Pk)  (Fk),  Plane  Name. 

Program_History:  Program_Code  (Pk),  Program_GraduationOOterm_Code  (Pk), 

Program_EffectiveOOterm_Code  (Pk),  SSAN  (Pk)  (Fk),  Input_Date,  Faculty _Advisor_SSAN, 
Class_Code,  Program_Year_Prefix,  Ed_Level_Code,  ASC_Code,  Login_Name, 
EffectiveOOquarter_Code,  Effective_Year_Prefix,  Career_Pointer_Code,  AFIT_Degree_Code. 

Program_STD_Sections:  SSAN  (Pk)  (Fk),  Section  Number  (Pk). 

Rank_History:  SSAN  (Pk)  (Fk),  Grade_Rank_Abbrev  (Pk),  Grade_Rank_Date,  Login_Name, 

Input_Date,  Manning_Code,  Branch_Service_Code. 

Recall_Roster:  SSAN  (Pk)  (Fk),  Home_Phone_Number,  Next_In_Chain_SSAN. 

Registration_Verification:  SSAN  (Pk)  (Fk),  Term  Code,  Quarter  Code,  Year  Prefix, 
Registration_Notice. 

Resident_Student:  SSAN  (Pk)  (Fk),  Academic_Action_Code,  Overdue_Indicator,  Classification_Code, 
Part_Record_Indicator,  Admin  Hold  Indicator,  MajorOOASC_Code,  MajorOOed_Level_Code, 
Program  Code  ,  Program_GraduatlonOOterm_Code,  Class_Code  ,  Program_Year_Prefix, 
Selected_Type_Code,  AFIT_Degree_Code,  GraduationOOterm  Code  ,  GraduationOOquarter  Code 
,  Graduation  Year  Prefix,  Grad  Status  Code,  Departure  Date,  Box  Number,  Card  Number, 
Encoded_Card_Number,  Library  Number,  Locker  Number,  Admit_Date, 
Student_Sponsor_SSAN,  EntryOOterm  Code,  EntryOOquarter_Code,  Entry_Year_Prefix, 
Admission_Type_Code,  Admission  Action  Code,  Career  Pointer  Code,  GainingOOAFSC  Code, 
Faculty  Advisor  SSAN,  RegistrationOOdepartment  Code ,  Program  EffectiveOOterm  Code, 
EffectiveOOquarter_Code,  Effective  Year  Prefix,  Leader_Code,  Program  Section  Number, 
GainOOMAJCOM_Abbrev,  GainOOduty  Station,  LosingOOMAJCOM  Abbrev,  Pse  Code. 

Section  Leaders:  Leader  Code  (Pk),  SSAN  (Pk)  (Fk),  Program  Code,  Class  Code, 
ProgramSectionNumber. 

Selected  Comments:  SSAN  (Pk)  (Fk),  Selected  Comment. 

Selected_Projection:  SSAN  (Pk)  (Fk),  GainOOMAJCOM  Code,  GainOOMAJCOM  Abbrev, 

Galn  MAJCOM  Supervisor,  Gain_MAJCOM_Supervisor_Phone,  Gain_MAJCOM_DSN_Prefix, 
Gain  MAJCOMOODepartment  Code,  Position  Number  Projected. 

Selected_Student:  SSAN  (Pk)  (Fk),  SelectedOOASC  Code,  SelectedOOed_Level_Code, 

Selected  Quota  Year,  SelectedOOewi  Option  Code,  Pca  indicator,  Quota  Program  Code, 

List  Number,  Report_No_Earlier_Than_Date,  Report_No_Later_Than_Date, 
Projected_Start_Date,  Assign  Avail  Date,  Assign_Reason_Code,  MAJCOM  Abbrev, 
Projected_Entry_Class,  Selected  Date,  Input  Date,  Login_Name,  Selected_Type_Code, 
SelectedOOAFSC  Code,  Reselection  Code,  MPC_School_Code,  Pse_Code, 
AssignOOdepartment_Code. 
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Selected_Student_Archive:  Selected  Quota  Year  (Pk),  SSAN  (Pk)  (Fk),  SelectedOOASC  Code, 

SelectedOOed_Level_Code,  SelectedOOewi  Option  Code,  Pca_Indicator,  Quota  Program  Code, 
List_Number,  Report_No_Earlier_Than_Date,  Report_No_Later_Than_Date, 
Projected_Start_Date,  Assign  Avail  Date,  Assign_Reason_Code,  MAJCOM  Abbrev, 
Projected_Entry_Class,  Selected  Date,  Input  Date,  Login_Name,  Selected_Type_Code, 
SelectedOOAFSC  Code,  GainOOMAJCOM  Code,  GainOOMAJCOM  Abbrev, 

Gain  MAJCOM  Supervisor,  Gain  MAJCOM  DSN  Prefix,  Gain  MAJCOM  Supervisor  Phone, 
Gain  MAJCOMOOdepartment  Code,  Position  Number  Projected,  Reselection  Code,  Pse  Code, 
MPC_School_Code,  AssignOOdepartment  Code. 

Sponsors_Country_Prefere:  SSAN  (Pk)  (Fk),Ce,  PreferredOOcountry  Code  (Pk), 

Spouse_Info:  SSAN  (Pk)  (Fk),  Spouse_Birth_Date  ,  Spouse  Fname ,  Spouse  Lname, 

Spouse_At_AFIT_Indicator,  Spouse  Nickname,  Spouse_In_Military_Indicator, 

Spouse  Occupation,  Spouse  Remarks. 

Student:  SSAN  (Pk)  (Fk),  Last_Name,  First  Name,  Department  Code,  Grade  Rank  Abbrev, 

Program  Code,  Class  Code,  Grad  Term,  Date_Entered,  Revision  Date. 

Student_Address:  SSAN  (Pk)  (Fk),  Address  Type  (Pk),  Address_Type_Desc,  Address_Line_l, 
Address_Line_2,  City,  State,  ZIP,  ZIP  Ext. 

Student_Courses:  Course_Prefix_Code  (Pk)  (Fk),  Course  Number  (Pk)  (Fk),  Course_Section  (Pk)  (Fk), 
SSAN  (Pk)  (Fk),  Term  Code,  Hours,  Grade,  Calculated  Field. 

Student_Duty_History:  Duty_Sequence_Number  (Pk),  SSAN  (Pk)  (Fk),  Duty_Title,  DutyOOAFSC_Code, 
Duty  Organization,  Duty_Station,  Duty_Assigned_Date,  Login_Name. 

Student_Sequences:  Program_Sequence_Code  (Pk),  SSAN  (Pk)  (Fk). 

Term_Entry:  SSAN  (Pk)  (Fk),  EntryOOterm_Code,  EntryOOquarter  Code,  Entry_Year_Prefix, 
Admission_Type_Code,  Admission  Action  Code. 

Term_Entry_History:  SSAN  (Pk)  (Fk),  EntryOOterm_Code,  EntryOOquarter_Code,  Entry_Year_Prefix, 
Admission_Type_Code,  Admission_Action_Code. 

Test_Scores:  Test_Type_Code  (Pk),  SSAN  (Pk)  (Fk),  Test_Taken_Date,  Test_Score,  Login_Name, 
Input_Date. 

TDY_Attendees:  SSAN  (Pk)  (Fk),  Left_For_TDY_Date  (Pk),  Retumed_From_TDY_Datee, 
TDY_Destination_Code,  TDY_Purpose. 

Thesis_Diss_Book_Allowance:  SSAN  (Pk)  (Fk),  Allowance  Code,  ASC  Code,  ED  Level  Code. 

Transcript_SSANS_105643:  SSAN  (Pk)  (Fk),  Last_Name,  First  Name,  Middle_Initial,  Name_Suffix, 
Grade_Rank_Abbrev,  Program_Code,  Selected_Type_Code,  Table  indicator. 

Transcript_Sent:  SSAN  (Pk)  (Fk),  Transcript_Sent_Date  (Pk),  Num_Transcript_Sent. 

Transfer_Transcript:  SSAN  (Pk)  (Fk),  Course  Prefix  Code  (Pk),  Course_Number  (Pk), 

Transfer  Course  Prefix  (Pk),  Transfer  Course  Number  (Pk),  Course  Section, 

AFITOOCredit  Hours,  Eamed  Hours  Indicator,  GPA  lndicator,  Transfer_Credit_Hours, 
TransferOOGrade  Code,  Transfer  Start  Date,  Transfer  End  Date,  MPC  School  Code, 
Soche_Indicator,  TmsfrOOTerm  Code,  TmsfrOOQuarter  Code,  TmsfT_Year_Prefix, 
TmsfrOOCareer  Pointer  Code,  Transfer  Course  Title,  Transcrip_Course_Title. 

Wait_List:  SSAN  (Pk)  (Fk),  Course_Prefix_Code  (Pk),  Course  Number  (Pk),  Course  Section  (Pk). 

Waived_Course:  WaivedOOcourse  Prefix  Code  (Pk),  WaivedOOcourse  Number  (Fk), 

Course  Prefix  Code  (Pk)  (Fk),  Course  Number  (Pk)  (Fk),  Course  Section  (Pk)  (Fk),  SSAN  (Pk) 
(Fk),  WaivedOOgrade  Code,  Waived  Date. 
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Appendix  B:  The  Entity  Relationship  Diagram 


Figure  11:  ER  diagram  (Person) 
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Figure  12:  ER  diagram  (Resident  Student  1) 
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Figure  13:  ER  diagram  (Resident  Student  2) 
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Figure  14:  ER  diagram  (Resident  Student  3) 
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Appendix  C:  The  Object  Model 


Figure  15:  Person ’s  Object  Model 


^This  model  does  not  show  all  the  associations  related  to  this  object 


Figure  16:  Person  Object  Model  (cont.) 
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■^This  model  does  not  show  all  the  associations  related  to  this  object 


Figure  17:  Resident  Student  Object  Model 
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■^This  model  does  not  show  all  the  associations  related  to  this  object 


Figure  18:  Resident  Student  Object  Model  (cont.) 
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Figure  19:  Grade  History  Association 
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Figure  20:  Grade  Change  History  Association 
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Figure  21:  Student  Courses  Association 


Figure  22:  Dropped  Course  Association 


Figure  23:  Waived  Course  Association 
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Figure  24:  Education  History  Association 
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Person  Structure  Definition 


Object  Name:  Person 
Object  Number: 

Object  Description:  General  model  of  a  person 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/25/96 
History:  Thesis 

Superclass:  None 
Components:  None 
Context:  None 

Attributes: 


SSAN 

SSAN  type 

Social  Security  Account  Number. 

lastname 

String 

Person’s  last  name. 

firstname 

String 

Person’s  first  name. 

name  _prefix 

Prefix  type 

Name  prefix. 

name  suffix 

Suffix  type 

Name  suffix. 

middle _initial 

Character 

Name  middle  initial. 

gender 

{male,  female} 

birthjdate 

Date  type 

Birth  date. 

marital_status 

{single,  married,  divorced,  widow} 

race 

Race  type 

Person’s  race. 

religion 

Religion  type 

Person’s  religion. 

ethnic_group 

Ethnic  type 

Person’s  ethnicity. 

badge_number 

Badge  number  type 

Badge  number. 

emailjaddress 

String 

Electronic  mail  address. 

academ  ic_ed_status 

Academiced  type 

Academic  education  status. 

dutyjide 

String 

Duty  title. 

duty _phone 

Phone  type 

Duty  phone  number. 

department  code 

Department  type 

Person’s  department. 

citizenship jcountry 

Country  type 

Person’s  country. 

login  name 

String 

Login  name  of  who  made  changes. 

input_date 

Date  type 

Date  of  last  change. 

Constraints: 

Z  Static  Schema: 

Let  SSAN_TYPE  be  the  set  of  all  Social  Security  Account  Numbers. 

Let  DATE  TYPE  be  the  set  of  all  possible  dates. 

Let  PREFIX_TYPE  be  the  set  of  all  possible  name  prefixes. 

Let  SUFFIX_TYPE  be  the  set  of  all  possible  name  suffixes. 

Let  RACE  TYPE  be  the  set  of  all  possible  races. 

Let  RELIGION_TYPE  be  the  set  of  all  possible  religions. 

Let  ETHNIC_TYPE  be  the  set  of  all  possible  ethnic  groups. 

Let  BADGE_NUMBER_TYPE  be  the  set  of  all  possible  badge  numbers. 

Let  ACADEMIC_ED_TYPE  be  the  set  of  all  possible  academic  education  types. 
Let  PHONE_TYPE  be  the  set  of  all  possible  phone  numbers. 

Let  DEPARTMENT_TYPE  be  the  set  of  all  possible  departments. 

Let  COUNTRY_TYPE  be  the  set  of  all  possible  country  codes. 
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^Person  _ 

SSAN :  SSANJTYPE 
lastname  :  String 
firstname :  String 
name ^prefix :  PREFIX  TYPE 
name  suffix :  SUFFIX  TYPE 
middle Jnitial  :  Character 
gender :  {male,  female} 
birth_date :  DATE  TYPE 
race :  RACE  TYPE 

marital_status  :  (single,  married,  divorced,  widow} 
religion  :  RELIGION  TYPE 
email  address :  String 

academic  ed  status :  ACADEMIC  ED  TYPE 
ethnic_group :  ETHNIC  TYPE 
citizenship  country  :  COUNTRY JTYPE 
departmentjcode :  DEPARTMENTJTYPE 
duty  title :  String 
duty jjhone  :PHONE_TYPE 
badge_number :  BADGE_TYPE 
login  name :  String 
input jiate :  DATEJTYPE 
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Military  Structure  Definition 


Object  Name:  Military 
Object  Number: 

Object  Description:  General  model  of  a  military 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/27/96 
History:  Thesis 

Superclass:  Person 
Components:  None 
Context:  None 


Attributes: 


rank 

Rank  type 

Military  rank. 

branch 

Branch  type 

Branch  of  service. 

date  of  rank 

Date  type 

Date  of  rank. 

AFSC 

AFSC  type 

AFSC  code. 

date_of_commission 

Date  type 

Date  of  commission. 

date_of_separation 

Date  type 

Date  of  separation. 

manning_code 

Manning  type 

Manning  code. 

DEROS_date 

Date  type 

DEROS  date. 

duty_effective_date 

Date  type 

Date  of  effective  duty. 

aero  rating_code 

Aerorating  type 

Aero  rating  code. 

MAJCOM 

MAJCOM  type 

MAJCOM  code. 

base 

Base  type 

Base  code. 

blue_chip_indicator 

Character 

Blue  chip  indicator. 

NCOJndicator 

Boolean 

NCO  indicator. 

MPC_code 

MPC  type 

MPC  code. 

recall_roster 

Person  pointer 

Pointer  to  another  military. 

Constraints: 

Z  Static  Schema: 

Let  RANK_TYPE  be  the  set  of  all  possible  rank  types. 

Let  BRANCH_TYPE  be  the  set  of  all  possible  branch  types. 

Let  DATE_TYPE  be  the  set  of  all  possible  dates. 

Let  MANNING_TYPE  be  the  set  of  all  possible  manning  types. 

Let  AERO_RATING_TYPE  be  the  set  of  all  possible  aero  rating  types. 
Let  MAJCOM_TYPE  be  the  set  of  all  possible  MAJCOM  types. 

Let  BASE_TYPE  be  the  set  of  all  possible  base  types. 

Let  MPC  TYPE  be  the  set  of  all  possible  MPC  types. 

Let  PERSON_POINTER_TYPE  be  a  pointer  to  a  particular  person. 
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Military  _ 

rank :  RANK  TYPE 

branch :  BRANCH JTYPE 

date_of_rank :  DATE  TYPE 

AFSC :  AFSCJYPE 

date_of_commission :  DATE  TYPE 

dateof  separation  :  DATE  JTYPE 

manning  code :  MANNINGJTYPE 

DEROS_date :  DATE  TYPE 

duty _ejf active _date  :  DATEJTYPE 

aero_rating_code  :  AERO  RATING  TYPE 

MAJCOM:  MAJCOMJTYPE 

base :  BASEJYPE 

blue  chip  indicator :  Character 

NCO  indicator :  Boolean 

MPC_code :  MPC  TYPE 

recall_roster  :  P EPSON  POINTERJTYPE 
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Student  Structure  Definition 


Object  Name:  Student 
Object  Number: 

Object  Description:  General  model  of  student 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/27/96 
History:  Thesis 

Superclass:  Person 
Components:  None 
Context:  None 

Attributes: 

Part  Record  Indicator 
Ed_Level 
Selected_Type 
Gaining_AFSC 
GainJdAJCOM 
Gain_duty_Station 
Losing_MAJCOM 
PSE 

Last_Year_Attended 

Constraints: 

Z  Static  Schema: 

Let  EDUCATION_LEVEL_TYPE  be  the  set  of  all  education  level  types. 
Let  SELECTED_TYPE  be  the  set  of  all  possible  selected  types. 

Let  AFSC_TYPE  be  the  set  of  all  possible  AFSC  types. 

Let  MAJCOM__TYPE  be  the  set  of  all  possible  MAJCOM  types. 

Let  DUTY_STATION_TYPE  be  the  set  of  all  possible  duty  stations. 

Let  PSE_TYPE  be  the  set  of  all  possible  PSE  types. 

Let  YEAR_TYPE  be  the  set  of  all  possible  years. 


Educationlevel  type 
Selected  type 
AFSC  type 
MAJCOM  type 
DutyStation  type 
MAJCOM  type 
PSE  type 
Year  type 


If  a  student  is  resident  or  part  time. 
Major  education  level. 

School  that  has  been  selected. 

The  AFSC  that  he  is  going. 

The  MAJCOM  that  he  is  going. 
Duty  station  he  is  going. 

The  MAJCOM  that  he  is  losing. 
The  professional  specialized  educ. 
The  last  year  he  attended  a  schooll. 


^Student  - 

Part_Record_Indicator :  Boolean 
Ed_Level :  EDUCATION _LEVEL_TYPE 
Selected  Type :  SELECTEDJTYPE 
Gaining_AFSC :  AFSC_TYPE 
Gain  MAJCOM:  MAJCOM  TYPE 
Gain jduty  Station  :  DUTY_STATION_TYPE 
LosingJAAJCOM :  MAJCOMJTYPE 
PSE :  PSEJTYPE 
Last  Year  Attended :  YEAR  TYPE 
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Resident  Student  Structure  Definition 


Object  Name:  Resident  Student 
Object  Number: 

Object  Description:  General  model  of  resident  student 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/27/96 
History:  Thesis 

Superclass:  Student 
Components:  None 
Context:  None 

Attributes: 


Academic  Tcf/o«  Academic  Action  type  Student’ 

s  academic  standing. 

Overdue  Indicator 

Boolean 

If  a  student  has  an  overdue  book. 

Classification 

Classification  type 

Represents  an  enrollment  classific. 

MajorASC 

ASC  type 

Major  Academic  specialty. 

Program 

Program  type 

Student’s  Program. 

Class 

Class  type 

Student’s  class. 

Program_Year 

Year  type 

Prefix  of  the  program  year. 

AFIT_Degree 

Degree  type 

Type  of  AFIT  degree. 

Career _Pointer_Code 

Career  pointer  type 

Level  of  education  that  credit  apply 

Departure _Date 

Date  type 

Departure  date  from  AFIT. 

Box_Number 

Box  type 

Student’s  box  number. 

Card_Number 

Card  type 

Student’s  card  number. 

Library _Number 

LibraryNumber  type 

Student’s  library  number. 

Locker _Number 

Locker  type 

Student’s  locker  number. 

Student _Sponsor 

Person  pointer 

Pointer  to  sponsor. 

Faculty _Advisor 

Person  pointer 

Pointer  to  faculty  advisor. 

Constraints: 

Z  Static  Schema: 

Let  ACADEMIC_ACTION  _TYPE  be  the  set  of  all  possible  academic  actions. 
Let  CLASSIFICATION_TYPE  be  the  set  of  all  possible  classification  types. 
Let  ASC_TYPE  be  the  set  of  all  possible  ASC  types. 

Let  PROGRAM_TYPE  be  the  set  of  all  possible  programs. 

Let  CLASS_TYPE  be  the  set  of  all  possible  class  types. 

Let  YEAR  TYPE  be  the  set  of  all  possible  years. 

Let  DEGREE_TYPE  be  the  set  of  all  possible  degree  types. 

Let  CAREER_POINTER_TYPE  be  the  set  of  all  possible  career  pointer  types. 
Let  DATE_TYPE  be  the  set  of  all  possible  dates. 

Let  BOX_TYPE  be  the  set  of  all  possible  boxes. 

Let  CARD_POINTER_TYPE  be  the  set  of  all  possible  card  pointer  types. 

Let  LIBRARY_NUMBER_TYPE  be  the  set  of  all  possible  library  numbers. 
Let  LOCKER_TYPE  be  the  set  of  all  possible  locker  numbers. 

Let  PSE_TYPE  be  the  set  of  all  possible  PSE  types. 

Let  PERSON_POINTER_TYPE  be  a  pointer  to  a  particular  person. 


69 


^Resident  student  - 

Academic _Action  :  ACADEMIC  ACTION JYPE 

Overdue _Indicat or  :  Boolean 

Classification :  CLASSIFICATION _TYPE 

Major JlSC  :  ASCJYPE 

Program  :  PROGRAM  TYPE 

Class  :  CLASS_TYPE 

Program  Year :  YEAR  TYPE 

AFIT  Degree :  DEGREE  TYPE 

Career  PointerJCode :  CAREER  POINTER  TYPE 

Departure _Date :  DATEJTYPE 

Box_Number :  BOX  TYPE 

Card  Number  :  CARDJTYPE 

Library  Number :  LIBRARY_NUMBER_TYPE 

Locker  Jdumber :  LOCKER  TYPE 

Student  Sponsor :  PERSON  POINTER  TYPE 

Faculty  Advisor :  PERSON_POINTER_TYPE 


70 


INTL-Student  Structure  Definition 


Object  Name:  INTL-Student 
Object  Number: 

Object  Description:  General  model  of  INTL-student 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/27/96 
History:  Thesis 

Superclass:  Resident  Student 
Components:  None 
Context:  None 


Attributes: 


WSCN 

WSCN  type 

Work  Sheet  Control  Number. 

ITO 

ITO  type 

ITO  number. 

Case_number 

Casenumber  type 

Case  number. 

DLI  request Jndicator 

Boolean 

If  student  has  to  attended  DLI. 

DLIJndicator 

Boolean 

If  student  attended  DLL 

evaluation_reqjdate 

Date  type 

Date  evaluation  was  requested. 

requested _program 

Program  type 

Requested  student’s  Program. 

eval J'orwardjiate 

Date  type 

Evaluation  forward  date. 

forwardjojiept 

Department  type 

Department  it  was  forwarded. 

Eval_returned_date 

Date  type 

Date  the  evaluation  returned. 

admissionjstatus 

Admission  type 

Admission  status  code. 

eval_remarks 

String 

Evaluation  remarks. 

country _notified_date 

Date  type 

Date  the  country  was  notified. 

AFSA  T_notified_date 

Date  type 

Date  that  AFSAT  was  notified. 

AFSA  TjquotaJndicator 

Boolean 

If  student  fills  a  country’s  quota. 

firstjsponsor 

Person  pointer 

Pointer  to  sponsor. 

second_sponsor 

Person  pointer 

Pointer  to  sponsor. 

sourcejjfJimds 

Funds  type 

Source  of  funds  code. 

AFSA  T_country 

Country  type 

The  home  country  of  a  student. 

Constraints: 

Z  Static  Schema: 

Let  WSCN  _TYPE  be  the  set  of  all  possible  WSCN  numbers. 

Let  ITO_TYPE  be  the  set  of  all  possible  ITO  numbers. 

Let  CASE_NUMBER_TYPE  be  the  set  of  all  possible  case  numbers. 
Let  DATE_TYPE  be  the  set  of  all  possible  dates. 

Let  PROGRAM_TYPE  be  the  set  of  all  possible  programs. 

Let  DEPARTMENT_TYPE  be  the  set  of  all  possible  department  types. 
Let  ADMISSION_TYPE  be  the  set  of  all  possible  admission  types. 

Let  PERSON_POINTER_TYPE  be  a  pointer  to  a  particular  person. 
Let  FUNDS_TYPE  be  the  set  of  all  possible  funds  types. 

Let  COUNTRY_TYPE  be  the  set  of  all  possible  country  types. 
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^INTL-student  - 

WSCN:  WSCNJTYPE 
ITO :  ITOJYPE 

Case_number :  CASE_NUMBER_TYPE 
DLI_request_Jndicator :  Boolean 
DLI  indicator  :  Boolean 
evaluation  reqjiate :  DATE  TYPE 
requested  jrogram  :  PROGRAM  TYPE 
eval J'orward  date :  DATEJTYPE 
forward Jo  dept :  DEPARTMENT JTYPE 
Evalj-eturned  date :  DATE  TYPE 
admission_status :  ADMISSION _TYPE 
eval  remarks :  String 
country  notifled  date :  DATEJTYPE 
AFSAT_notified_date :  DATE  TYPE 
AFSAT  quota  indicator :  Boolean 
first  sponsor :  PERSON_POINTERJTYPE 
second  sponsor :  PERSON_POINTER_TYPE 
source _ofJunds  :  FUNDS JTYPE 
AFSAT_country :  COUNTRYJYPE 
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Address  Structure  Definition 


Object  Name:  Address 
Object  Number: 

Object  Description:  General  model  of  address 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/25/96 
History:  Thesis 

Superclass:  None 
Components:  None 
Context:  None 

Attributes: 


address  type 

Address  type 

Address  type. 

address 

String 

Address. 

city 

String 

City. 

state 

State  type 

State. 

country 

Country  type 

Country. 

zipcode 

Zip  type 

Zip  code. 

phone 

Phone  type 

Phone  number. 

address_effective_date 

Date  type 

Date  of  effective  address. 

login_name 

String 

Login  name  of  who  made  changes. 

loginjdate 

Date  type 

Date  of  last  change. 

Constraints: 

Z  Static  Schema: 

Let  ADDRESS_TYPE  be  the  set  of  all  possible  address  types. 
Let  STATE  TYPE  be  the  set  of  all  possible  states. 

Let  COUNTRY_TYPE  be  the  set  of  all  possible  country  codes. 
Let  ZIP  TYPE  be  the  set  of  all  possible  zip  codes. 

Let  PHONE  TYPE  be  the  set  of  all  phone  Numbers. 

Let  DATE_TYPE  be  the  set  of  all  possible  dates. 


(—  Address  _ 

address  type  :  String 

address  :  String 

city :  String 

state :  STATE  TYPE 

zipcode  :  ZIPJTYPE 

country :  COUNTRY  TYPE 

phone :  PHONEJTYPE 

address  effective  date  :  DA  TEJTYPE 

login  name :  String 

login  date :  DATE  TYPE 


73 


Dependent  Information  Structure  Definition 


Object  Name:  Dependent  Information 
Object  Number: 

Object  Description:  General  model  of  dependent  information 


Author:  Maj  Pedro  Arthur 
Date:  03/26/96 

History:  Thesis 

Superclass:  None 
Components:  None 
Context:  None 

Linhares  Lima 

Attributes: 

number  children 

Integer 

Number  of  student’s  children. 

single jdep_chldrn 

Character 

Indicator  if  single  with  children. 

deps_at_A  FIT 

Character 

Indicator  if  dependents  at  AFIT. 

Constraints: 

Z  Static  Schema: 


^Dependent  Information  - 

number_children :  Integer 
single _dep_chldrn:  Character 
deps_at_AFIT:  Character 
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Education  History  Structure  Definition 


Object  Name:  Education  History 
Object  Number: 

Object  Description:  General  model  of  education  history 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/26/96 
History:  Thesis 

Superclass:  None 
Components:  None 
Context:  None 


Attributes: 


MPC  School  Code 

MPC  type 

Military  Persoimel  Center  school. 

Ed  Level  Code 

Edlevel  type 

Education  level. 

Type_Degree_Code 

Typedegree  type 

Type  of  degree. 

ASCjCode 

ASC  type 

Academic  specialty  code. 

Quality _Pomts 

Integer 

Quality  points. 

Total_Credit_Hours 

Integer 

Total  of  credit  hours. 

Method_Pf_Obtainment 

Methodofobt  type 

Method  of  obtained  an  education. 

A  cadent  ic_Ed_Status 

Academiced  type 

Academic  education  status. 

Last_  Year_A  ttended 

Date  type 

Last  year  that  attended  a  school. 

ABET_Accredited 

Boolean 

If  AFIT  degree’s  ABET  accredited. 

Ed_History_Remarks 

String 

Education  history  remarks. 

WorkJDJProcessed 

WorkID  type 

Action  that  orig.  a  transaction. 

Logm_Name 

String 

Login  name  of  who  made  changes. 

InputJDate 

Date  type 

Date  of  last  change. 

Operators  Jnitials 

String 

Operator’s  initials. 

TrnscrptjCareer  Pointer  Transcript  type 

Education  level  of  student  transcr. 

Duty_Location 

Dutylocation  type 

Location  of  active  duty. 

Degree_Cum_Gpa 

Integer 

The  cumulative  student’s  GPA. 

DegreeJTitle 

Degree  type 

The  title  of  a  student’s  degree. 

Constraints: 

Z  Static  Schema: 

Let  MPC  TYPE  be  the  set  of  all  possible  MPC  types. 

Let  ED_LEVEL_TYPE  be  the  set  of  all  possible  education  level  types. 

Let  TYPE_DEGREE_TYPE  be  the  set  of  all  possible  degree  types. 

Let  ASC_TYPE  be  the  set  of  all  possible  ASC  types. 

Let  DATE  TYPE  be  the  set  of  all  possible  dates. 

Let  METHOD_OF_OBT_TYPE  be  the  set  of  all  possible  method  of  obtained  types. 
Let  ACADEMIC_ED_TYPE  be  the  set  of  all  possible  academic  education  types. 

Let  WORK_ID_TYPE  be  the  set  of  all  possible  work  ID  types. 

Let  TRANSCRIPT_TYPE  be  the  set  of  all  possible  transcript  types. 

Let  DUTY_LOCATION_TYPE  be  the  set  of  all  possible  duty  location  types. 

Let  DEGREE_TYPE  be  the  set  of  all  possible  degree  types. 
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[—  Education  History  - 

MFC _School  Code  :  MPCJYPE 

Ed_Level_Code :  ED_LEVEL_TYPE 

Type  Degree  Code :  TYPE  DEGREE  TYPE 

ASC_Code :  ASC  TYPE 

Quality  Points :  Integer 

Total jOredit  Hours :  Integer 

Method  Of  Obtainment  :METHOD_OF_OBT_TYPE 

Academic_Ed_Status :  ACADEMIC  ED  TYPE 

Last JYear_Att ended :  DATE  TYPE 

ABET_Accr edited :  Boolean 

Ed  History  Remarks :  String 

WorkJD  Processed :  WORKJD  TYPE 

Login_Name :  String 

Input  Date :  DATE  TYPE 

Operators  Initials :  String 

TrnscrptjCareer  Pointer :  TRANSCRIPTJTYPE 

Duty_Location :  DUTY_LOCATION_TYPE 

Degree_Cum_Gpa :  Integer 

DegreeJTitle :  DEGREEJTYPE 
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Emergency  Data  Structure  Definition 


Object  Name:  Emergency  Data 
Object  Number: 

Object  Description:  General  model  of  emergency  data 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/27/96 
History:  Thesis 

Superclass:  None 
Components:  None 
Context:  None 


Attributes: 


Contact_Fname 

String 

Emergency  contact  first  name. 

ContactLname 

String 

Emergency  contact  last  name. 

Relation 

Relation  type 

The  relationship  with  a  person. 

Address 

String 

Home  address. 

City 

String 

Home  city. 

State 

State  type 

Home  state. 

Zipcode 

Zip  type 

Home  zip  code. 

Country 

Country  type 

Person’s  country. 

Phone 

Phone  type 

Home  phone  number. 

Firm_Name_Ojfice 

Office  type 

Person’s  office  symbol. 

Additional _Address 

String 

Additional  address  information. 

Street _Address 

String 

Additional  street  information. 

Address  _Room_Type 

Room  type 

Additional  Room  type. 

Address  _Room_Number 

String 

Additional  room  number. 

Street_Type_Code 

Street  type 

Additional  street  type. 

Revision_Name 

String 

Name  of  who  made  the  revision. 

Revision_Date 

Date  type 

Revision  date. 

LoginName 

String 

Login  name  of  who  made  chang 

LoginDate 

Date  type 

Date  of  last  change. 

Constraints: 

Z  Static  Schema: 

Let  RELATION_TYPE  be  the  set  of  all  possible  relationship  types. 
Let  STATE  TYPE  be  the  set  of  all  possible  states. 

Let  ZIP  TYPE  be  the  set  of  all  possible  zip  codes. 

Let  COUNTRY_TYPE  be  the  set  of  all  possible  country  codes. 

Let  PHONE_TYPE  be  the  set  of  all  phone  numbers. 

Let  OFFICE_TYPE  be  the  set  of  all  possible  offices. 

Let  ROOM_TYPE  be  the  set  of  all  possible  room  types. 

Let  STREET_TYPE  be  the  set  of  all  possible  street  types. 

Let  DATE_TYPE  be  the  set  of  all  possible  dates. 
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Emergency  data  - 

Contact  Fname :  String 

Contact JLname :  String 

Relation  :  RELATION _TYPE 

Address :  String 

City :  String 

State :  STATE J'YPE 

Zipcode :  ZIPJTYPE 

Country :  COUNTRYJYPE 

Phone :  PHONEJTYPE 

Firm  NamejOfficel :  OFFICE  TYPE 

Additional  Address :  String 

Street _Address :  String 

Address _Room_Type :  ROOMJTYPE 

Address _Room_Number :  String 

Street JTypeJCode  :  STREET JTYPE 

RevisionJLame :  String 

Revision_pate  :  DATEJTYPE 

Login JIame :  String 

Login_Date :  DATEJTYPE 
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Spouse  Information  Structure  Definition 


Object  Name:  Spouse  Information 
Object  Number: 

Object  Description:  General  model  of  spouse  information 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/27/96 
History:  Thesis 

Superclass:  None 
Components:  None 
Context:  None 

Attributes: 


BirthDate 

Date  type 

Spouse  birth  date. 

Fname 

String 

Spouse  first  name. 

Lname 

String 

Spouse  last  name. 

Spouse _At_AF IT 

Boolean 

If  spouse  came  with  him/her. 

Nickname 

String 

Spouse  nickname. 

Spouse_In_Military 

Boolean 

If  spouse  in  military  service. 

Occupation 

String 

Spouse  occupation. 

Remarks 

String 

Remarks. 

Constraints: 

Z  Static  Schema: 

Let  DATE_TYPE  be  the  set  of  all  possible  dates. 


l— Spouse  Information  _ 

Birth_Date :  DATEJTYPE 
Fname  :  String 
Lname :  String 
Spouse_At_AFIT :  Boolean 
Nickname :  String 
Spouse _In_Military :  Boolean 
Occupation  :  String 
Remarks  :  String 
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Student  Duty  History  Structure  Definition 


Object  Name:  Student  Duty  History 
Object  Number: 

Object  Description:  General  model  of  student  duty  history 

Author:  Maj  Pedro  Arthur  Linhares  Lima 
Date:  03/27/96 
History:  Thesis 

Superclass:  None 
Components:  None 
Context:  None 

Attributes: 

Title 
AFSC 

Organization 
Duty_Station 
Assigned_Date 
Sequence  _Number 
Login_Name 

Constraints: 

Z  Static  Schema: 

Let  TITLE_TYPE  be  the  set  of  all  possible  titles. 

Let  AFSC_TYPE  be  the  set  of  all  possible  AFSC  types. 

Let  DUTY_STATION_TYPE  be  the  set  of  all  possible  duty  stations. 
Let  DATE_TYPE  be  the  set  of  all  possible  dates. 


1  uie  lype 
AFSC  type 
String 

DutyStation  type 
Date  type 
Integer 
String 


Job  title. 

Duty  AFSC. 

Where  the  student  works. 
Student’s  duty  station. 

Date  the  student  was  assigned. 
Sequence  number. 

Login  name. 


(—  Student  duty  history _ 

Title  :  TITLE  TYPE 

AFSC :  AFSC_TYPE 

Organization  :  String 

Duty_Station :  DUTY_STATIONJTYPE 

Assigned  Date  :  DATE  TYPE 

Sequence  J^umber  :  Integer 

Login  Name  :  String 
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Test  Scores  Structure  Definition 


Object  Name:  Test  Scores 
Object  Number: 


Object  Description;  General  model  of  test  scores 

Author:  MaJ  Pedro  Arthur  Linhares  Lima 

Date:  03/27/96 

History:  Thesis 

Superclass:  None 

Components:  None 

Context:  None 

Attributes: 

TestJType 

Test  type 

Type  of  test. 

Taken_Date 

Date  type 

The  date  of  the  test. 

Score 

Integer 

Score  on  the  test. 

InpujDate 

Date  type 

The  date  of  the  input. 

Login_Name 

String 

Login  name. 

Constraints: 

Z  Static  Schema: 

Let  TEST_TYPE  be  the  set  of  all  possible  test  types. 
Let  DATE_TYPE  be  the  set  of  all  possible  dates. 


Test  scores  _ 

TestJType :  TESTJTYPE 
Taken__Date :  DATEJYPE 
Score :  Integer 
Input _Date :  DATEJTYPE 
LoginJIame  :  String 
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Appendix  D:  The  Functional  Model 


Figure  25:  STARS  Application  Level  0  DFD 
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invalid  selection 


Figure  26:  Perform  Action  Level  1 DFD 
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selection 


invalid 


Menu  Options 


validate 

valid  (use 

Jype) 

verify 

display 

login 

user_type 

options 

k J 

L _ J 

_ 

_ ; 

selection 


2^ 


user 

selection 


verify  user 
selection 


Return  I  ▼  selection 


Database 


•N 

handle 

selection 

J 

Exit 


Figure  27:  Menu  Option  Level  2  DFD 


8' 


selection 


Figure  28:  Handle  Selection  Level  2  DFD 
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selection 

data 


return 


Figure  29:  Perforin  Selection  Level  3  DFD 


8' 


Figure  31:  Perform  Update  Level  4  DFD 
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Figure  32:  Perform  Deletion  Level  4  DFD 
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Appendix  E:  Implementation  of  the  Object  Model 


^Fields:  i 

;|  ssan 
if  maior_asc 
academic_act 
if  overduejndic 
program 
ii  class 

if  program_year ; 
if  box_number 
iOllIndexes; 
fssan 


ssan 

grade_rank_date 

grade_rank_abbre' 

manning_code 


ssan 

rank 

date_of_rank 

afsc 

date_of_comm' 

manning_code 

CDlndexes: 

'^ssan 


^Fields' 

ssan 

lasLname  [ 
first_name  , 
middlejnitiall 
login_name 
birth_date 
race 
gender 
religion 
CBindexes: 
fssan 


^Fields:  ; 

ssan 

part_record_indical 

last_year_altended 

edjevel 

selected_tvpe 

CDlndexes: 

fssan 


^Fields: 


maior_asc 

academic_a 

overdue_in 

program 

class 

program_ye 

box_number 

fflindexes: 

fssan 


Database  Designer  -  Stars 


^Fields: 

ssan  « 

^  ssan 

part  ,  record  indicaC''"' 

grade  < 

;  last_j)ear_attended; 

date  of  grade  f 

ed_level  j; 

manning_code  < 

selected_tvpe 

CDlndexes:  ^  ! 

ilM 

CBindexes: 

fssan  ^ 

I"  fssan  ^ 

Figure  33:  Table ’s  relationship  in  STARS  Database 
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Class  Designef  -  stars  class,  vex  (person) 


PERSON 


Properties  stars  class. vex 


Last  Name:  First  Name: 


Middle 


S5AN 


LAST  NAME  FIRST  NAME1 


SSAN1 


Birthdate:  BIRTH  D 


DERI 


Religion:  RELIGI0N1 


Login  Name:  LOGIN„  NAM 


RACE) 


3  •  Sizable  Border 


PERSON 


ClipControls  .T.  -  true  (Default) 


T.  -  True  tDefaul:i' 


Figure  34:  Person ’s  Class 


91 


Class  Designer  -  stars  class. vex  (militarjr] 


PERSON 


MILITARY 


Last  Name:  First  Name: 


Middle: 


SSAN 


LAST  NAME  FIRST  NAME1 


SSAN1 


Birthdate:  BiRTH_D 


GENDER1 


Religion:  RELIGION1 


Login  Name:  LOGIN_NAM 


RACE1 


SSAN 


SSAN1 


RANK1 


DATE  OF 


Date  of  commission: 


Date  of  rank:  DATE  OF 


Manning  Code:  MANNING_COD 


AFSC1 


AFSC: 


Fwra;  I  Forml 


LayoJ^  p> 


ftxmsef 


FormCount 

Forms 

Name 

ParentClass 

WindowType 


Fo/msef 
0  -  Modeless 


Figure  35:  Military ’s  Class 


Figure  36:  Military _student’s  Class 
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^  Class  Designer  -  stars  class.vcx  (niilitai5i resident^student| 


PERSON 


SSAN; 


Last  Name;  First  Name; 


Middle; 


SSAN1 


LAST  NAME 


FIRST  NAME1 


MIDI 


Birthdate; 


BIRTH_D 

Gender; 

GENDER1 

Religion; 

RELIGION1 


Login  Name; 


LOGIN  NAM 


Race; 


RACE1 


SSAN 


SSAN1 


Part  Time;  PI 
La^  Year  Alt.; 


Edij.  Level;! 


Selected  T^e: 


ATTE 


ED  LEVEL 


SELECTED 


SSAN; 


SSAN1 


Rarrie; 

i 

RANK1 

1 

pate  of  tank;  AFSC; 


DATE  OF 


AFSC1 


P  ate  of .  PPrnnlss^n: 


DATE  OF 


JManning  Code; 


MANNING  COD 


SSAN: 


■i 

■ 

Major  ASC; 

Acad.  Actiw; 


Box  ft; 


SSAN1 


MAJOR  ASCI 


ACADEMIC  ACT 


NOM 


Overdue,  jnd..: 


IE  INDIC 


Pregratti; 


PROGRA 


.C|a.ss;. 


CLASS1 


.Prpgrajn  Year 


lAM  Y 


-*.1.  J 

Rptir 


^tm:  I  Person4  3 


Figure  37:  Military _resident_student’s  Class 
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Class  Designer  -  stars  class. vex  (militaiji intl student) 


r/PERSO® 


bBIIT^wl.studewV 


Last  Name;  First  Name: 


LAST  NAME  FIRST  NAME1 


Birthdate:  BIRTH_D 
Login  Name;  LOGIN_NAM 


GENDER1  Religion:  I  RELIGiONI 
RACEl  I 


Middle;!  SSAN:| 

I  Part  Time:  p 
I  Last  Veiar  Aitt.; 

’  Edu.  Level;: 

;  5  ejected  Tjipe; 


SSAN1 


ATTE 

ED_LEVEL 

SELECTED 


BHS1|T7^Cjn1lT7WbM1I 


Pate  of  rank; 


AFSC; 


SSAN1 

RANK1 

DATE_OF 

■ 

AFSC1 

1 

1  SSANl 

Dale  of.  cpmmissjBn:,  DATE_0F|  Marinirig  Code;  I  MANNING_COD 


''1'  MIL  RESIDENT  SflllTENT 


j  WSCN; 
llTp;.... 


WSCN1 

IT01 


Major  ASC;  : 

SSAN1  I  i  MAJOR  ASCI 


Acad.  Action; 


I  Case  tt;^  CASE  NUMBER 


J  |ACADEMIt:j!tCT||  D|:(  -Req:  f,^;g]- . ^ 


i.pyer.due.IndL:. iE_INDIC  Program;  PROGRA  ..Cbss:| CLASS1 


DLTTriit  IN 


Figure  38:  Military JNTLjtudent’s  Class 
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Class  Designer  -  stars  class,  vex  (civilian_person) 

1  ■;/  PERSON 

J 

SSAN: 

Last  Name: 

First  Name: 

Middle: 

SSAN1 

LAST_NAME 

FIRST_NA}.!E1 

111 

Birthdate; 


BIRTH_D 

Gender: 

GENDER1 

Religion: 

RELIGIONI 


Login  Name:  LOGIN_NAM  Race:  RACE1 


CIVILIAN 


ssan; 


SSAN1 


HHE 


Grade:  Diate  bf  Grade:  Hanriing  Code: 


GRADE1 


DATE  OF 


Jj  J  ___ 

Form:  Iforml  3  PaflcJ 


n 


Figure  39:  Civilian’s  Class 
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Figure  40:  Civilianjstudent’s  Class 
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Class  Designer  -  stars  class. vex  [civiliar^resident^studenl) 


•;/PEftSOM  ■ 


SSAN: 


Last  Name: 


First  Name: 


Middle: 


SSAN1 


LAST  NAME 


FIRST  NAME1 


MIDI 


Birthdate: 


BIRTH_D 

Gender: 

6ENDER1 

Religion: 

RELIGI0N1 


Login  Name:  LOGIN_NAM  Race:  RACE1 


CIVILIAN 


SSAN: 


Grade: 


Date  of  Grade:  Manrfing  Code: 


SSAN1 


GRADE1 


DATE  OF 


CIV  RESIDENT  STUDENT 


!  Ssain: 


Major  ASC: 


SSAN1 


MAJOR  ASCI 


BiBi 


SSAN: 


SSAN1 


Part  Time: 

■  El 


Acad,  A^d.Pn 
i  Program) 


ACADEMiC_A1  I  . . JO ye/du^.lnd;:.  VERDUE 


PROGRAI 


Cl^ss: 


Las^  Yegr  At|end^d: .  J  J  E 

Ed.  Level:  I  ED  LEVEL 


GRAM 


Dint  ti;' 


'PicrgraraiYead 

llJ 


Formsi  Eorml  ^1  Page:  [ 


Figure  41:  Civilian_resident_student’s  Class 
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Class  Designer  -  stars  class. vex  (civilian intl student) 


Ifl 


SSAN; 


Last  Name;  First  Name; 


Middle; 


SSAN1 


LAST  NAME 


FIRST  NAME1 


MIDI 


Birthdate; 


BlRTH_D 

Gender; 

GENDERl 

Religion; 

RELIGIONI 


Login  Name; 


L0GIN_NAM 

Race; 

RACE1 

Case  It: 

CASE_NUMBE1 

CIVJNTL_...  HBB 


I  SSAN; 
WSCN; ; 
ITO; 


SSAN  I 


WGCNl 


1101 


SSAN: 


Grade; 


Date  of  GiadK  Manriing  Codef 


SSAN1 

GRADE1 


DATE  or 


DLiReq.'Ind. 
DL(  Ind; 


DL 


DL 


d 


rsv  f  IT-ENT  ITililE 


Ssw; 


Major  iASC; 

1 SSAN; 

SSAN1 

MAJ0R_ASC1 

j 

SSAN1 

Figure  42:  Civilian_lNJL_student’s  Class 
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Class  Designer  -  stars  class. vex  (address) 


Middle; 


SSAN:  Last  Name:  First  Name; 

SSAN1  |last_name|  I  first  namei 


Birthdate:|BIRTH_D|  Gender:  GENDER1  Religion;  RELIGIONI 
Login  Name:  LOGIN_NAM  Race:  RACE1 


■ADDRESS 


hisMI 


SSANr 


SSAN1  Address  Effective  Date;  ADDRE5* 


Address  Tipe:  ADD_TYPE 

Address:... I  adDRESSI 


Phone  tt 


• .  .  State: :  • 


STATE1 


...Eountiv:  ..  C0UNTRY1 


.Z)P.Code;i 


PH0NE1 


ZIP  C0DE1 


Form:  Address 


Page: 


''  V  >'  ^  ^  .  A  \  ^ 


Figure  43:  Address  ’  Class 
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Appendix  F:  List  of  Abbreviations 


AFIT  -  Air  Force  Institute  of  Technology 

AFITSIS  -  Air  Force  Institute  of  Teehnology  Student  Information  System 

AFIT/SC  -  Air  Force  Instimte  of  Technology  Communication  Computer 
System 

CASE  -  Computer-Aided  Software  Engineering 
DBA  -  Database  Administrator 
DBMS  -  Database  Management  System 
DFD  -  Data  Flow  Diagram 
ER  -  Entity  Relationship 

OODBMS  -  Object-Oriented  Database  Management  System 
RDB  -  Relational  Database 

RDBMS  -  Relational  Database  Management  System 

SQL  -  Structured  Query  Language 

STARS  -  Student  Tracking  and  Registration  System 
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